From laing at bigpond.net.au Sun Feb 1 08:29:52 2004 From: laing at bigpond.net.au (The Laing Family) Date: Sun, 01 Feb 2004 18:29:52 +1100 Subject: [En-Nut-Discussion] External Power SUpply In-Reply-To: <000b01c3e821$3e646ec0$0100a8c0@ikarus2> Message-ID: Hi, This is probably a dumb question, but I HAVE read the doco and been unable to find enlightenment there. How do you power an Ethernut 2 board from an external 5V power supply? I know the simple answer is you use the screw terminals next to the RS 485 jumper block, and you jumper together pins 1 and 2, and pins 3 and 4. But which polarity do you connect to which screw terminal?! I'm very heistant to simply experiment after Harald's dire warnings of the likely consequences!! Thanks, Simon From harald.kipp at egnite.de Sun Feb 1 11:30:18 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Sun, 01 Feb 2004 11:30:18 +0100 Subject: [En-Nut-Discussion] CVS Release Branch 3.4 Occured In-Reply-To: <000b01c3e821$3e646ec0$0100a8c0@ikarus2> References: <5.1.1.6.0.20040130140149.03111e08@egnite.de> Message-ID: <5.1.1.6.0.20040201112815.01b91210@egnite.de> Hi Marc, At 18:39 31.01.2004 +0100, you wrote: >For what I dont understand is why there are differences (right now as of >2004-01-31) > between the nut-3_4-branch branch and the nut-3_4-release branch. >(cvs diff -r nut-3_4-branch nut) Did you update the checked out nut-3_4-release branch? There will be a difference in os/version.c and appload/. Harald From harald.kipp at egnite.de Sun Feb 1 11:43:02 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Sun, 01 Feb 2004 11:43:02 +0100 Subject: [En-Nut-Discussion] External Power SUpply In-Reply-To: References: <000b01c3e821$3e646ec0$0100a8c0@ikarus2> Message-ID: <5.1.1.6.0.20040201113242.01b91358@egnite.de> Hi Simon, You do right using extreme caution. 5V supply is possible only at the expansion port. But you may have to protect IC8, I assume. The screw terminal supply is connected to DC, which is after the rectifier bridge but before the regulator. Setting jumpers on JP6 1-2 and 3-4 will disable the diode and R26 as required. Contacts 3 of the terminal should be connected to minus (GND) and contact 4 to plus (7V) of your power supply. Contact 4 is the one near the mounting hole. To make sure you got the right contacts, supply the board with the barrel connector and measure the screw terminal contacts. You'll find the same polarity there. Harald At 18:29 01.02.2004 +1100, you wrote: >Hi, > >This is probably a dumb question, but I HAVE read the doco and been unable >to find enlightenment there. > >How do you power an Ethernut 2 board from an external 5V power supply? I >know the simple answer is you use the screw terminals next to the RS 485 >jumper block, and you jumper together pins 1 and 2, and pins 3 and 4. But >which polarity do you connect to which screw terminal?! I'm very heistant to >simply experiment after Harald's dire warnings of the likely consequences!! > >Thanks, > >Simon > >_______________________________________________ >En-Nut-Discussion mailing list >En-Nut-Discussion at egnite.de >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From harald.kipp at egnite.de Sun Feb 1 20:38:17 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Sun, 01 Feb 2004 20:38:17 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms Message-ID: <5.1.1.6.0.20040201202852.0325d438@egnite.de> Hi, Some files in CVS had been split by CPU families: os/timer.c: tmr_arm.c tmr_avr.c tmr_h8.c tmr_m68k.c os/thread.c: ctx_arm.c ctx_avr.c ctx_h8.c ctx_m68k.c In addition include/compiler.h had been split into files located in subdir include/cpu/. These changes are far from compilability, except AVRGCC. Other candidates are 1. Atomic functions 2. Enter/Exit critical functions 3. Checksum calculation 4. Interrupt stuff I have currently now idea, wich compilers I should chose in the first place for ARM7TDMI, H8/300 or Coldfire. Linux seems to be no big problem. Can anybody recommend any pre-build binaries for Win32? Thanks, Harald From damian at commtech.com.au Mon Feb 2 01:28:17 2004 From: damian at commtech.com.au (Damian Slee) Date: Mon, 2 Feb 2004 08:28:17 +0800 Subject: [En-Nut-Discussion] Supporting Other Target Platforms Message-ID: I'm not sure if this helps, there appears to be toolchains for ARM on the eCos site. Haven't used them though. http://ecos.sourceware.org/getstart.html -----Original Message----- From: Harald Kipp [mailto:harald.kipp at egnite.de] Sent: Monday, 2 February 2004 3:38 AM To: Ethernut User Chat (English) Subject: [En-Nut-Discussion] Supporting Other Target Platforms Hi, Some files in CVS had been split by CPU families: os/timer.c: tmr_arm.c tmr_avr.c tmr_h8.c tmr_m68k.c os/thread.c: ctx_arm.c ctx_avr.c ctx_h8.c ctx_m68k.c In addition include/compiler.h had been split into files located in subdir include/cpu/. These changes are far from compilability, except AVRGCC. Other candidates are 1. Atomic functions 2. Enter/Exit critical functions 3. Checksum calculation 4. Interrupt stuff I have currently now idea, wich compilers I should chose in the first place for ARM7TDMI, H8/300 or Coldfire. Linux seems to be no big problem. Can anybody recommend any pre-build binaries for Win32? Thanks, Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From ngbmoreau at yahoo.com.au Mon Feb 2 01:32:45 2004 From: ngbmoreau at yahoo.com.au (NGB) Date: Mon, 2 Feb 2004 11:32:45 +1100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <5.1.1.6.0.20040201202852.0325d438@egnite.de> References: <5.1.1.6.0.20040201202852.0325d438@egnite.de> Message-ID: <1075681965.401d9aadb4f5c@tiger.enttec> Harald I have scripts to build a arm-elf with newlib tool chain, they work under Linux and Cygwin. If you do use a pre built binary make sure you know how it was built, otherwsie it can lead to hours of fustration. email me if you want the scripts, they are based on crosstool-0.25 Nic > I have currently now idea, wich compilers I should > chose in the first place for ARM7TDMI, H8/300 or Coldfire. > Linux seems to be no big problem. > Can anybody recommend any pre-build binaries for Win32? ------------------------------------------------- From enut at ixo.de Mon Feb 2 09:10:18 2004 From: enut at ixo.de (Waschk,Kolja) Date: Mon, 2 Feb 2004 09:10:18 +0100 (CET) Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <5.1.1.6.0.20040201202852.0325d438@egnite.de> References: <5.1.1.6.0.20040201202852.0325d438@egnite.de> Message-ID: > wich compilers I should > chose in the first place for ARM7TDMI, H8/300 or Coldfire. [...] > Can anybody recommend any pre-build binaries for Win32? http://www.OCDemon.com has GNU gcc 2.95.3+binutils+gdb/insight for ARM. They're popular for their JTAG adapters. The "Wiggler" is the very basic one, just level shifters on parallel port (cheapest ready made clone is ARM-JTAG from Olimex, http://www.olimex.com ). The OCDemon "Raven" is the most basic one with Linux host support (cheapest ready made clone is the Chameleon POD from Amontec, http://www.amontec.com ). Looking at ARM targets, I'd suggest to select a particular configuration and document this selection for first steps. There are so many options, e.g. little vs big endian memory, presence of MMU, FPU, ... Many of these options have to be taken into account when configuring and building the toolchain. For example, a lot of toolchains have a libc with floating point instructions that wouldn't even disappear if you give the proper "no-fpu" compile options. A reasonable configuration for an "ARM Ethernut" could be - ARM7 core (Architecture v4) - Thumb instructions available - MMU not available - FPU not available - little endian memory (seems to be more common) Regards, Kolja -- mr. kolja waschk - haubach-39 - 22765 hh - ger phone +49 40 889130-34 - fax -35 - e-mail s.a. From jdx at slackware.pl Mon Feb 2 03:15:57 2004 From: jdx at slackware.pl (Jan Dubiec) Date: 02 Feb 2004 03:15:57 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <5.1.1.6.0.20040201202852.0325d438@egnite.de> References: <5.1.1.6.0.20040201202852.0325d438@egnite.de> Message-ID: <87vfmqxm3m.fsf@hs001.slackware.pl> On Sun, 01 Feb 2004 20:38:17 +0100, Harald Kipp wrote: > Hi, > > Some files in CVS had been split by CPU families: > > os/timer.c: tmr_arm.c tmr_avr.c tmr_h8.c tmr_m68k.c > os/thread.c: ctx_arm.c ctx_avr.c ctx_h8.c ctx_m68k.c IMO there should be created "arch" directory with MCU/CPU dependent subdirectories in it - please look at arch directory in the Linux kernel sources as an example. Then the above files should be moved to appropriate subdirectories. So finally there should be two eg. timer.c files: first under "os" directory which should contain hardware independent functions and the second under eg. "arch/h8300" with hardware dependent stuff. Next, IMO it isn't elegant using #if defined(__AVR_ATmega128__) || defined(__AVR_ATmega103__) #include "tmr_avr.c" #elif defined(__arm__) #include "tmr_arm.c" #elif defined(__H8300__) #include "tmr_h8.c" #elif defined(__m68k__) #include "tmr_m68k.c" #endif IMO better solution is to compile all hardware dependent files separately and consolidate them into one library, let's say libarch.a. We should also take into account that different devices can be build on the same MCU/CPU, eg. there are different EVBs for H8/3068F. [.....] > Other candidates are > > 1. Atomic functions > 2. Enter/Exit critical functions > 3. Checksum calculation > 4. Interrupt stuff 5. os/nutinit.c 6. Serial port stuf (initialization, enabling/disabling and control) 7. EEPROM stuff - AFAIK avr-gcc and Imagecraft do supply library with appropriate functions, H8 gcc doesn't > I have currently now idea, wich compilers I should > chose in the first place for ARM7TDMI, H8/300 or Coldfire. Of course gcc. ;-) At least for H8/300H. > Linux seems to be no big problem. > Can anybody recommend any pre-build binaries for Win32? Please look at http://www.kpitgnutools.com - you can find there Linux and Windows gcc binaries for H8/300H and SuperH MCU families. In order to download them you have to create an account first. Regards, /J.D. -- Jan Dubiec, jdx at slackware.pl, mobile: +48 602 101787 G??boka wiara wymaga p?ytkiego rozumu i nik?ej wiedzy. From nut at imsystems.ru Mon Feb 2 10:45:01 2004 From: nut at imsystems.ru (Roman Avramenko) Date: Mon, 2 Feb 2004 12:45:01 +0300 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <87vfmqxm3m.fsf@hs001.slackware.pl> References: <87vfmqxm3m.fsf@hs001.slackware.pl> Message-ID: <4531.040202@imsystems.ru> Hello Jan, Monday, February 02, 2004, 5:15:57 AM, you wrote: >> os/timer.c: tmr_arm.c tmr_avr.c tmr_h8.c tmr_m68k.c >> os/thread.c: ctx_arm.c ctx_avr.c ctx_h8.c ctx_m68k.c JD> IMO there should be created "arch" directory with MCU/CPU dependent JD> subdirectories in it - please look at arch directory in the Linux JD> kernel sources as an example. Then the above files should be moved to JD> appropriate subdirectories. So finally there should be two eg. timer.c JD> files: first under "os" directory which should contain hardware independent JD> functions and the second under eg. "arch/h8300" with hardware dependent JD> stuff. Right, also I think it will be better to have common arch/armnommu directory with separate system subdirs: arch/armnommu/snds100 -> Samsung S3C4510 (and probably S3C4530) ARM arch/armnommu/netarm -> NetARM arch/armnommu/atmel -> Atmel AT91 etc.. -- Best regards, Roman mailto:nut at imsystems.ru From harald.kipp at egnite.de Mon Feb 2 11:43:32 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 02 Feb 2004 11:43:32 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <87vfmqxm3m.fsf@hs001.slackware.pl> References: <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040201202852.0325d438@egnite.de> Message-ID: <5.1.1.6.0.20040202112338.031f81d8@egnite.de> Hi Jan and others, At 03:15 02.02.2004 +0100, you wrote: >On Sun, 01 Feb 2004 20:38:17 +0100, Harald Kipp wrote: > > Hi, > > > > Some files in CVS had been split by CPU families: > > > > os/timer.c: tmr_arm.c tmr_avr.c tmr_h8.c tmr_m68k.c > > os/thread.c: ctx_arm.c ctx_avr.c ctx_h8.c ctx_m68k.c >IMO there should be created "arch" directory with MCU/CPU dependent >subdirectories in it - please look at arch directory in the Linux >kernel sources as an example. Then the above files should be moved to >appropriate subdirectories. So finally there should be two eg. timer.c >files: first under "os" directory which should contain hardware independent >functions and the second under eg. "arch/h8300" with hardware dependent Frankly, most posters vote for the structure used with Linux, but without actually pointing to any advantage. Btw. "standard" is often a weak argument, IMO. >stuff. Next, IMO it isn't elegant using >#if defined(__AVR_ATmega128__) || defined(__AVR_ATmega103__) >#include "tmr_avr.c" >#elif defined(__arm__) >#include "tmr_arm.c" >#elif defined(__H8300__) >#include "tmr_h8.c" >#elif defined(__m68k__) >#include "tmr_m68k.c" >#endif >IMO better solution is to compile all hardware dependent files >separately and consolidate them into one library, let's say libarch.a. No, it isn't elegant but proofed in dev/usart.c to produce the least duplicate code. On the other hand, creating hardware dependant libraries simplifies the make process configuration. >We should also take into account that different devices can be build >on the same MCU/CPU, eg. there are different EVBs for H8/3068F. > >[.....] > > Other candidates are > > > > 1. Atomic functions > > 2. Enter/Exit critical functions > > 3. Checksum calculation > > 4. Interrupt stuff >5. os/nutinit.c >6. Serial port stuf (initialization, enabling/disabling and control) >7. EEPROM stuff - AFAIK avr-gcc and Imagecraft do supply library with > appropriate functions, H8 gcc doesn't OK. > > I have currently now idea, wich compilers I should > > chose in the first place for ARM7TDMI, H8/300 or Coldfire. >Of course gcc. ;-) At least for H8/300H. As far as I found out, almost all ARM compilers are GCC. But there seem to be different binary distributions, at least for the Win32 platform. For most Linux flavors building the toolchain is simple. But on Windows this might be a pain. > > Linux seems to be no big problem. > > Can anybody recommend any pre-build binaries for Win32? >Please look at http://www.kpitgnutools.com - you can find there Linux >and Windows gcc binaries for H8/300H and SuperH MCU families. In order >to download them you have to create an account first. Any good reason, why to prefer this one? Thanks, Harald From harald.kipp at egnite.de Mon Feb 2 12:03:53 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 02 Feb 2004 12:03:53 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <1075681965.401d9aadb4f5c@tiger.enttec> References: <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040201202852.0325d438@egnite.de> Message-ID: <5.1.1.6.0.20040202114503.01c28218@egnite.de> Hi Nic, At 11:32 02.02.2004 +1100, you wrote: >I have scripts to build a arm-elf with newlib tool chain, they work under >Linux >and Cygwin. I'd prefer MingW to avoid these DLL conflicts, but Cygwin seems to be supported by default. >If you do use a pre built binary make sure you know how it was built, >otherwsie >it can lead to hours of fustration. While doing the first steps with arm-gcc, I was hit by the fact, that I had to modify the linker files to get the program compiled for a specific ARM CPU. IMO, this is unacceptable for most Nut/OS users. >email me if you want the scripts, they are based on crosstool-0.25 Many thanks for your offer to help. I can accept to build my own binaries, but I'll never be able to support this for other users. Most Nut/OS newbies will not distinguish between Nut related topics and problems with their GCC build. If you look to this mailing list's archives, many questions are related to AVR chips, HTML/CGI problems or even the C language in general. I'd like to keep the steps towards the first running program as simple as possible. Today's newbies are tomorrow's gurus, if they don't get frustrated in the first five minutes. Harald From harald.kipp at egnite.de Mon Feb 2 12:23:06 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 02 Feb 2004 12:23:06 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <5.1.1.6.0.20040201202852.0325d438@egnite.de> Message-ID: <5.1.1.6.0.20040202122205.01c385b0@egnite.de> > >I have currently now idea, wich compilers I should Did I write this wonderfully crafted piece of crap? :-) Harald From harald.kipp at egnite.de Mon Feb 2 12:19:45 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 02 Feb 2004 12:19:45 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: References: <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040201202852.0325d438@egnite.de> Message-ID: <5.1.1.6.0.20040202120557.03268890@egnite.de> Hi Kolja, At 09:10 02.02.2004 +0100, Waschk,Kolja wrote: > > wich compilers I should > > chose in the first place for ARM7TDMI, H8/300 or Coldfire. [...] > > Can anybody recommend any pre-build binaries for Win32? > >http://www.OCDemon.com has GNU gcc 2.95.3+binutils+gdb/insight for ARM. Isn't 2.95 a little bit outdated? >Looking at ARM targets, I'd suggest to select a particular configuration >and document this selection for first steps. There are so many options, e.g. >little vs big endian memory, presence of MMU, FPU, ... Many of these options >have to be taken into account when configuring and building the toolchain. >For example, a lot of toolchains have a libc with floating point instructions >that wouldn't even disappear if you give the proper "no-fpu" compile options. That's also my experience with arm-gcc. And I think it is neccessary to have something pre-configured for Windows, if this exists. On Linux a well documented build process is sufficient. No idea, how's the situation with OS/X, but I guess it's similar to Linux up to a certain extend. Being forced to install the full Cygwin development toolchain and watching tons of warnings while the cross compiler is build, wouldn't attract many potential users. >A reasonable configuration for an "ARM Ethernut" could be > > - ARM7 core (Architecture v4) > - Thumb instructions available > - MMU not available > - FPU not available > - little endian memory (seems to be more common) We selected the AT91R40008 for the first step. I expected something other than Atmel again, and other chips are superior in many aspects (DMA, more IOs). But the 256k internal RAM is the killer argument. Harald From hyun at argostech.co.kr Mon Feb 2 12:58:55 2004 From: hyun at argostech.co.kr (Lee hyun-Keun) Date: Mon, 2 Feb 2004 20:58:55 +0900 Subject: [En-Nut-Discussion] NutTcpConnect() question. Message-ID: <003c01c3e983$ef31ed00$0200a8c0@narcisse> Hi, everyone. I'm new to this mailing list and to ethernut, I'm calling for your help... ;-) After some verification of my homemade hardware with your sample applications, I modified tcps.c to make it a tcp client. But if NutTcpConnect() is called when there is no server program listent on the port, the function never returns... i.e. 1) start server program first. turn on ethernut after : O.K. 2) turn on ethernut first, start server program after : Blocked on NutTcpConnect. packets captured on case (1) with ethereal shows: ethernut -> server port4097 > port7050 [SYN] Seq=1000000 Ack=0 Win=3216 Len=0 server->ethernut port7050 > port 4097 [RST, ACK] Seq=0 Ack=1000001 Win=0 Len=0 Thanks in advance for your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040202/e32e035a/attachment.html From Oliver.Schulz at bong.de Mon Feb 2 13:22:33 2004 From: Oliver.Schulz at bong.de (Oliver Schulz) Date: Mon, 2 Feb 2004 13:22:33 +0100 Subject: AW: [En-Nut-Discussion] NutTcpConnect() question. Message-ID: Hi Lee, this bug should be fixed in version 3.4.x. Which version of Nut/OS are you using? Look in os/version.c. Obtain the latest release from http://www.ethernut.de Cheers, Oliver. -----Ursprungliche Nachricht----- Von: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Lee hyun-Keun Gesendet: Montag, 2. Februar 2004 12:59 An: en-nut-discussion at egnite.de Betreff: [En-Nut-Discussion] NutTcpConnect() question. Hi, everyone. I'm new to this mailing list and to ethernut, I'm calling for your help... ;-) After some verification of my homemade hardware with your sample applications, I modified tcps.c to make it a tcp client. But if NutTcpConnect() is called when there is no server program listent on the port, the function never returns... i.e. 1) start server program first. turn on ethernut after : O.K. 2) turn on ethernut first, start server program after : Blocked on NutTcpConnect. packets captured on case (1) with ethereal shows: ethernut -> server port4097 > port7050 [SYN] Seq=1000000 Ack=0 Win=3216 Len=0 server->ethernut port7050 > port 4097 [RST, ACK] Seq=0 Ack=1000001 Win=0 Len=0 Thanks in advance for your help. From dferbas at dfsoft.cz Mon Feb 2 15:33:51 2004 From: dferbas at dfsoft.cz (Dusan Ferbas) Date: Mon, 02 Feb 2004 15:33:51 +0100 Subject: [En-Nut-Discussion] Re: Supporting Other Target Platforms In-Reply-To: <20040202112315.2BD2D2F42A5@p15095813.pureserver.info> References: <20040202112315.2BD2D2F42A5@p15095813.pureserver.info> Message-ID: <6.0.1.1.2.20040202152843.01bac290@pop3.servery.cz> If you want to build a Coldfire context switching it should be noticed that some of 68k instructions are not supported. Most important is absence of auto increment/decrement for movem. Maybe Coldfire will have diffferent low level module. No idea about free 68k compiler. I am using Metrowerks Codewarrior. >Some files in CVS had been split by CPU families: > >os/timer.c: tmr_arm.c tmr_avr.c tmr_h8.c tmr_m68k.c >os/thread.c: ctx_arm.c ctx_avr.c ctx_h8.c ctx_m68k.c Dusan From harald.kipp at egnite.de Mon Feb 2 15:52:43 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 02 Feb 2004 15:52:43 +0100 Subject: [En-Nut-Discussion] Version 3.4 Useful? Message-ID: <5.1.1.6.0.20040202154245.031ee2f0@egnite.de> First let me defend Lee: There's no official release of 3.4 yet, just a CVS snapshot. Talking about it, I'm wondering, who is actually using this release. Success reports by private email prefered. Please report problems here in the list. We just tested PPP in general and Shoutcast MP3 streaming over Ethernet. With MP3 we get hick-ups, which are typical for missing data. I can say for sure that the problem is not with the VS1001 driver. It's either caused by buffering or by TCP. We are using MSS of 1460 and 11680 bytes of window size. Harald From Baranov at intech21.com Mon Feb 2 15:56:28 2004 From: Baranov at intech21.com (Alexander Baranov) Date: Mon, 2 Feb 2004 09:56:28 -0500 Subject: [En-Nut-Discussion] Question about two network connections. Message-ID: <00bc01c3e99c$bcfdb760$1101000a@Alex> Hi, All. I have such a problem: I use two network oriented threads. Main thread periodically sends data through Inet using POST method of http protocol. Having sent the next potion of data, it obtains something as server reply and parses it as server command. Another thread, which I call DirectTCP, opens another socket and accepts data from port 23 - telnet like this: NutTcpAccept(dirsock, 23). It is supposed to be used for immediate incoming commands from the server. Actually, it works but sometimes it hangs up and the box is being reloaded by watchdog. I tried to investigate the situation and found that the 'tdp->td_memory' of the main thread after some time becomes not equal to DEADBEEF, which is interpreted as "CORRUPT" in one of the examples. I tried to free as much heap as possible and now I have almost 16K heap available, but I have not achieved stable work still. Maybe I have to upgrade the system? Judging from version.c I use 3.3.0.1. now. Please, advise. Thanks, Alexander Baranov From Oliver.Schulz at bong.de Mon Feb 2 16:38:42 2004 From: Oliver.Schulz at bong.de (Oliver Schulz) Date: Mon, 2 Feb 2004 16:38:42 +0100 Subject: AW: [En-Nut-Discussion] Version 3.4 Useful? Message-ID: Hi, > First let me defend Lee: There's no official > release of 3.4 yet, just a CVS snapshot. Right, I forgot about it. I fixed this bug in version 1.8 of net/tcpsm.c. If the tcp state machine is in TCPS_SYN_SENT state and a RST packet is received, the error code was set properly, but the caller of NutConnect wasn't noticed. So the call never returned. Cheers, Oliver. From lakab at telia.com Mon Feb 2 21:29:19 2004 From: lakab at telia.com (Lars Andersson) Date: Mon, 2 Feb 2004 21:29:19 +0100 Subject: [En-Nut-Discussion] POST method. In-Reply-To: <00bc01c3e99c$bcfdb760$1101000a@Alex> Message-ID: <002e01c3e9cb$3c1afb60$1601a8c0@p3> Hi all, a question triggered by Alexander Baranov's message today. Is there an example showing how to retrieve the query when using the POST method with CGI. This might not be the correct terminology but I hope you understand what I mean. I use GET with CGI but am bothered with the 256 byte limit. // Lars H. Andersson From Baranov at intech21.com Mon Feb 2 21:49:04 2004 From: Baranov at intech21.com (Alexander Baranov) Date: Mon, 2 Feb 2004 15:49:04 -0500 Subject: [En-Nut-Discussion] POST method. References: <002e01c3e9cb$3c1afb60$1601a8c0@p3> Message-ID: <001001c3e9cd$feaa0a70$1101000a@Alex> Hi, Lars. I am not sure that I've understood the question, but I can send you my code 'as is'. ----- Original Message ----- From: "Lars Andersson" To: "'Ethernut User Chat (English)'" Sent: Monday, February 02, 2004 3:29 PM Subject: [En-Nut-Discussion] POST method. > Hi all, > a question triggered by Alexander Baranov's message today. > > Is there an example showing how to retrieve the query when using > the POST method with CGI. This might not be the correct terminology > but I hope you understand what I mean. > > I use GET with CGI but am bothered with the 256 byte limit. > > // > Lars H. Andersson > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From lakab at telia.com Mon Feb 2 22:13:59 2004 From: lakab at telia.com (Lars Andersson) Date: Mon, 2 Feb 2004 22:13:59 +0100 Subject: [En-Nut-Discussion] POST method. In-Reply-To: <001001c3e9cd$feaa0a70$1101000a@Alex> Message-ID: <000001c3e9d1$7991f0b0$1601a8c0@p3> Alexander, When I use a CGI page with "method=GET" I can pick up query items using NutHttpGetParameter() calls, but if I would use "method=POST" I do not know how (or where) to find the query. Example: FormTop_P[] = "
"; I would like to say METHOD=\"POST\" instead. -----Original Message----- From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Alexander Baranov Sent: Monday, 02 February, 2004 21:49 To: Ethernut User Chat (English) Subject: Re: [En-Nut-Discussion] POST method. Hi, Lars. I am not sure that I've understood the question, but I can send you my code 'as is'. ----- Original Message ----- From: "Lars Andersson" To: "'Ethernut User Chat (English)'" Sent: Monday, February 02, 2004 3:29 PM Subject: [En-Nut-Discussion] POST method. > Hi all, > a question triggered by Alexander Baranov's message today. > > Is there an example showing how to retrieve the query when using > the POST method with CGI. This might not be the correct terminology > but I hope you understand what I mean. > > I use GET with CGI but am bothered with the 256 byte limit. > > // > Lars H. Andersson > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From lakab at telia.com Mon Feb 2 22:21:20 2004 From: lakab at telia.com (Lars Andersson) Date: Mon, 2 Feb 2004 22:21:20 +0100 Subject: [En-Nut-Discussion] Makefile automagic In-Reply-To: <000001c3e9d1$7991f0b0$1601a8c0@p3> Message-ID: <000201c3e9d2$80a05120$1601a8c0@p3> Hi group, Somewhere in the Make process this command line is generated rm httpd.elf can I suppress this in some way? I just can't find where it happens! Regards, Lars H. Andersson From Baranov at intech21.com Mon Feb 2 22:34:36 2004 From: Baranov at intech21.com (Alexander Baranov) Date: Mon, 2 Feb 2004 16:34:36 -0500 Subject: [En-Nut-Discussion] POST method. References: <000001c3e9d1$7991f0b0$1601a8c0@p3> Message-ID: <001a01c3e9d4$5ad8c4c0$1101000a@Alex> Hi. It seems to me that I've understood. I designed http client, sending http-requests, on Ethernut and http-server is made on remote web-server and is made by another developer on C#. And you AFAIU want to realize http-server on Ethernut . Sorry, I did not do that. Regards, Alex. ----- Original Message ----- From: "Lars Andersson" To: "'Ethernut User Chat (English)'" Sent: Monday, February 02, 2004 4:13 PM Subject: RE: [En-Nut-Discussion] POST method. > Alexander, > > When I use a CGI page with "method=GET" I > can pick up query items using NutHttpGetParameter() calls, > but if I would use "method=POST" I do not know > how (or where) to find the query. > > Example: > FormTop_P[] = " METHOD=\"GET\">"; > > I would like to say METHOD=\"POST\" instead. > > > > > -----Original Message----- > From: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Alexander > Baranov > Sent: Monday, 02 February, 2004 21:49 > To: Ethernut User Chat (English) > Subject: Re: [En-Nut-Discussion] POST method. > > > Hi, Lars. > I am not sure that I've understood the question, but I can send you my > code > 'as is'. > > ----- Original Message ----- > From: "Lars Andersson" > To: "'Ethernut User Chat (English)'" > Sent: Monday, February 02, 2004 3:29 PM > Subject: [En-Nut-Discussion] POST method. > > > > Hi all, > > a question triggered by Alexander Baranov's message today. > > > > Is there an example showing how to retrieve the query when using > > the POST method with CGI. This might not be the correct terminology > > but I hope you understand what I mean. > > > > I use GET with CGI but am bothered with the 256 byte limit. > > > > // > > Lars H. Andersson > > > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From enut at ixo.de Mon Feb 2 23:38:23 2004 From: enut at ixo.de (Waschk,Kolja) Date: Mon, 2 Feb 2004 23:38:23 +0100 (CET) Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <5.1.1.6.0.20040202120557.03268890@egnite.de> References: <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040202120557.03268890@egnite.de> Message-ID: Hi, > >http://www.OCDemon.com has GNU gcc 2.95.3+binutils+gdb/insight for ARM. > Isn't 2.95 a little bit outdated? In principle, yes. But unless you find a toolchain using 3.3 or 3.4 that isn't tagged "experimental", I'd recommend staying with 2.95.3. Especially if C++ isn't needed but just C and assembler. I agree that something like a WinAVR package for ARM would be really nice. However, I'm quite sure it wouldn't be a "WinARM" but rather a "WinAT91" or "WinLPC2X": "ARM" just isn't a synonym for some well-defined platform like "AVR" is. > We selected the AT91R40008 for the first step. > [...] > internal RAM is the killer argument. Probably it is wise to restrict ARM support in Nut/OS to platforms/CPUs that have something like this in common: no need for Megabytes of RAM nor ROM. >From my point of view, Nut/OS can provide an environment with threads and TCP/IP for targets with small memory. Anyone who has a "bigger" target could use uClinux or eCos or KADAK or ... Beside some Atmel CPUs, I'd like to see Philips LPC21xx supported. Yet they aren't available with external bus, but it is supposed to change soon. Even without external bus, having a TCP/IP stack can be useful with PPP etc... Kolja P.S. If you're wondering how I'm currently involved with both Nut/OS and ARM; I'm currently using Nut/OS on a Ethernut derivative that is supposed to add Ethernet connectivity to some industrial measurement device, and in parallel (for personal use only) work on adapting uClinux 2.4 and linux 2.6 to run on a ZyXEL router I happen to own (with Samsung S3C4510 CPU with ARM7TDMI). -- mr. kolja waschk - haubach-39 - 22765 hh - ger phone +49 40 889130-34 - fax -35 - e-mail s.a. From mikec at call-direct.com.au Mon Feb 2 23:45:10 2004 From: mikec at call-direct.com.au (Mike Cornelius) Date: Tue, 3 Feb 2004 09:45:10 +1100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <5.1.1.6.0.20040202112338.031f81d8@egnite.de> Message-ID: <01ec01c3e9de$37fdb050$2301a8c0@Mike> Jan Wrote:- >>Please look at http://www.kpitgnutools.com - you can find there Linux >>and Windows gcc binaries for H8/300H and SuperH MCU families. In order >>to download them you have to create an account first. Harald Wrote:- >Any good reason, why to prefer this one? Jan got in before me but I will second his sugestion. This is the toolchain I used when I ported Nut/OS to the H8 so the first reason to prefer it is that it's know to work, it installed without any trouble and I was up and running in only a few minutes. Secondly it's very well supported, KPIT are activly maintaining this release. Thirdly it is compatible with the HEW IDE which may be useful to some people. 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-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Harald Kipp Sent: Monday, February 02, 2004 9:44 PM To: Ethernut User Chat (English) Subject: Re: [En-Nut-Discussion] Supporting Other Target Platforms Hi Jan and others, At 03:15 02.02.2004 +0100, you wrote: >On Sun, 01 Feb 2004 20:38:17 +0100, Harald Kipp >wrote: > > Hi, > > > > Some files in CVS had been split by CPU families: > > > > os/timer.c: tmr_arm.c tmr_avr.c tmr_h8.c tmr_m68k.c > > os/thread.c: ctx_arm.c ctx_avr.c ctx_h8.c ctx_m68k.c >IMO there should be created "arch" directory with MCU/CPU dependent >subdirectories in it - please look at arch directory in the Linux >kernel sources as an example. Then the above files should be moved to >appropriate subdirectories. So finally there should be two eg. timer.c >files: first under "os" directory which should contain hardware >independent functions and the second under eg. "arch/h8300" with >hardware dependent Frankly, most posters vote for the structure used with Linux, but without actually pointing to any advantage. Btw. "standard" is often a weak argument, IMO. >stuff. Next, IMO it isn't elegant using >#if defined(__AVR_ATmega128__) || defined(__AVR_ATmega103__) #include >"tmr_avr.c" #elif defined(__arm__) >#include "tmr_arm.c" >#elif defined(__H8300__) >#include "tmr_h8.c" >#elif defined(__m68k__) >#include "tmr_m68k.c" >#endif >IMO better solution is to compile all hardware dependent files >separately and consolidate them into one library, let's say libarch.a. No, it isn't elegant but proofed in dev/usart.c to produce the least duplicate code. On the other hand, creating hardware dependant libraries simplifies the make process configuration. >We should also take into account that different devices can be build on >the same MCU/CPU, eg. there are different EVBs for H8/3068F. > >[.....] > > Other candidates are > > > > 1. Atomic functions > > 2. Enter/Exit critical functions > > 3. Checksum calculation > > 4. Interrupt stuff >5. os/nutinit.c >6. Serial port stuf (initialization, enabling/disabling and control) 7. >EEPROM stuff - AFAIK avr-gcc and Imagecraft do supply library with > appropriate functions, H8 gcc doesn't OK. > > I have currently now idea, wich compilers I should > > chose in the first place for ARM7TDMI, H8/300 or Coldfire. >Of course gcc. ;-) At least for H8/300H. As far as I found out, almost all ARM compilers are GCC. But there seem to be different binary distributions, at least for the Win32 platform. For most Linux flavors building the toolchain is simple. But on Windows this might be a pain. > > Linux seems to be no big problem. > > Can anybody recommend any pre-build binaries for Win32? >Please look at http://www.kpitgnutools.com - you can find there Linux >and Windows gcc binaries for H8/300H and SuperH MCU families. In order >to download them you have to create an account first. Any good reason, why to prefer this one? Thanks, Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From ngbmoreau at yahoo.com.au Mon Feb 2 23:52:32 2004 From: ngbmoreau at yahoo.com.au (NGB) Date: Tue, 3 Feb 2004 09:52:32 +1100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: References: <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040202120557.03268890@egnite.de> Message-ID: <1075762352.401ed4b04f3ab@tiger.enttec> > > In principle, yes. But unless you find a toolchain using 3.3 or 3.4 that > isn't > tagged "experimental", I'd recommend staying with 2.95.3. Especially if C++ > isn't needed but just C and assembler. I'm pretty sure GCC 3.3 has been tagged stable for ARM, a quick check on the arm linux malining list should confirm this. Nic ------------------------------------------------- From hyun at argostech.co.kr Tue Feb 3 02:26:52 2004 From: hyun at argostech.co.kr (Lee hyun-Keun) Date: Tue, 3 Feb 2004 10:26:52 +0900 Subject: [En-Nut-Discussion] POST method. References: <000001c3e9d1$7991f0b0$1601a8c0@p3> Message-ID: <003301c3e9f4$cd7eff10$0200a8c0@narcisse> To Lars, To get cgi input posted using POST method, I read from stdin up to the length obtained from : getenv("CONTENT_LENGTH") call in linux. You should perhaps find how to do it in Ethernut. Cheers ----- Original Message ----- From: "Lars Andersson" To: "'Ethernut User Chat (English)'" Sent: Tuesday, February 03, 2004 6:13 AM Subject: RE: [En-Nut-Discussion] POST method. > Alexander, > > When I use a CGI page with "method=GET" I > can pick up query items using NutHttpGetParameter() calls, > but if I would use "method=POST" I do not know > how (or where) to find the query. > > Example: > FormTop_P[] = " METHOD=\"GET\">"; > > I would like to say METHOD=\"POST\" instead. > > > > > -----Original Message----- > From: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Alexander > Baranov > Sent: Monday, 02 February, 2004 21:49 > To: Ethernut User Chat (English) > Subject: Re: [En-Nut-Discussion] POST method. > > > Hi, Lars. > I am not sure that I've understood the question, but I can send you my > code > 'as is'. > > ----- Original Message ----- > From: "Lars Andersson" > To: "'Ethernut User Chat (English)'" > Sent: Monday, February 02, 2004 3:29 PM > Subject: [En-Nut-Discussion] POST method. > > > > Hi all, > > a question triggered by Alexander Baranov's message today. > > > > Is there an example showing how to retrieve the query when using > > the POST method with CGI. This might not be the correct terminology > > but I hope you understand what I mean. > > > > I use GET with CGI but am bothered with the 256 byte limit. > > > > // > > Lars H. Andersson > > > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From enut at ixo.de Tue Feb 3 07:54:31 2004 From: enut at ixo.de (Waschk,Kolja) Date: Tue, 3 Feb 2004 07:54:31 +0100 (CET) Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <1075762352.401ed4b04f3ab@tiger.enttec> References: <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040202120557.03268890@egnite.de> <1075762352.401ed4b04f3ab@tiger.enttec> Message-ID: ngb> I'm pretty sure GCC 3.3 has been tagged stable for ARM The 3.3 gcc itself is, i.e. it produces correct assembler files from C - but Harald asked for a prebuilt toolchain, i.e. something that is also correctly assembling and linking. I met some basic problems when building a 3.3 + uclibc toolchain that would suit my particular target (big endian ARM without MMU and without FPU). That makes me wonder if available toolchains really have that all sorted out yet. Kolja -- mr. kolja waschk - haubach-39 - 22765 hh - ger phone +49 40 889130-34 - fax -35 - e-mail s.a. From bengt at florin.se Tue Feb 3 08:06:15 2004 From: bengt at florin.se (Bengt Florin) Date: Tue, 3 Feb 2004 08:06:15 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <1075762352.401ed4b04f3ab@tiger.enttec> Message-ID: <00d201c3ea24$3748dc70$0205a8c0@hugin> Found this for gcc 3.3.2 & 3.4. IIRC Harald doesn't like CygWin, but this is what you get. http://www.ariusdsp.com/gnuarm/gnuarm.html bengan -----Original Message----- From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de]On Behalf Of NGB Sent: den 2 februari 2004 23:53 To: enut at ixo.de; Ethernut User Chat (English) Subject: Re: [En-Nut-Discussion] Supporting Other Target Platforms > > In principle, yes. But unless you find a toolchain using 3.3 or 3.4 that > isn't > tagged "experimental", I'd recommend staying with 2.95.3. Especially if C++ > isn't needed but just C and assembler. I'm pretty sure GCC 3.3 has been tagged stable for ARM, a quick check on the arm linux malining list should confirm this. Nic ------------------------------------------------- _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From mwse at gmx.de Tue Feb 3 08:17:16 2004 From: mwse at gmx.de (Marc Wetzel) Date: Tue, 3 Feb 2004 08:17:16 +0100 Subject: [En-Nut-Discussion] Makefile automagic In-Reply-To: <000201c3e9d2$80a05120$1601a8c0@p3> Message-ID: <003601c3ea25$c1029f90$6401a8c0@ikarus2> For a one-shot I use `make httpd.elf` to get the file not deleted. /Marc > -----Original Message----- > From: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of > Lars Andersson > Sent: Monday, February 02, 2004 10:21 PM > To: 'Ethernut User Chat (English)' > Subject: [En-Nut-Discussion] Makefile automagic > > > Hi group, > > Somewhere in the Make process > this command line is generated > > rm httpd.elf > > can I suppress this in some way? > I just can't find where it happens! > > > Regards, > Lars H. Andersson > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-> nut-discussion > From ngbmoreau at yahoo.com.au Tue Feb 3 08:32:42 2004 From: ngbmoreau at yahoo.com.au (NGB) Date: Tue, 3 Feb 2004 18:32:42 +1100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <00d201c3ea24$3748dc70$0205a8c0@hugin> References: <00d201c3ea24$3748dc70$0205a8c0@hugin> Message-ID: <1075793562.401f4e9aaf19e@tiger.enttec> This one looks really good. But I suspect they have used the standard newlib, which needs to be hacked and rebuilt because the crt0.s file relies heavily on the ARM monitor (HaL I think). Harald I'm not sure you will be able to find an prebuilt toolchain for ARM that is as clean as Winavr. But this should not stop development on a Ethernut 4 ARM. Nic Quoting Bengt Florin : > Found this for gcc 3.3.2 & 3.4. > IIRC Harald doesn't like CygWin, but this is what you get. > > http://www.ariusdsp.com/gnuarm/gnuarm.html > > bengan ------------------------------------------------- From unreal at home.nl Tue Feb 3 00:12:10 2004 From: unreal at home.nl (Michel) Date: Tue, 3 Feb 2004 00:12:10 +0100 Subject: [En-Nut-Discussion] PPP fixes In-Reply-To: <01ec01c3e9de$37fdb050$2301a8c0@Mike> Message-ID: <002b01c3e9e1$fc84a250$6400a8c0@imhotep> Hi all, As promised, here are my fixes for PPP. Sorry it took so long :-) The last fixes I posted did not fix the case where an option that was rejected was longer than the option just in the front of it. Basically what I did was fix the CONFREJ by moving all remaining options to the front of the packet, not just the one being rejected. In NutLcpInput() and in NutPapInput() I also made a small improvement by setting the size of the network layer (nb_nw.sz) to the correct value. Although this didn't seem to be harmfull in any way, maybe it will prevent any future problems. These fixes have enabled me to succesfully dialin to some of the larger Dutch ISP's. To my regret, I noticed that I missed the closing date for an official release by just a few days. Ah well, better luck next time :-) Greetings Michel Hendriks -------------- next part -------------- A non-text attachment was scrubbed... Name: icmpin.c Type: application/octet-stream Size: 6590 bytes Desc: not available Url : http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040203/8e527a06/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: lcpin.c Type: application/octet-stream Size: 17126 bytes Desc: not available Url : http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040203/8e527a06/attachment-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: papin.c Type: application/octet-stream Size: 4695 bytes Desc: not available Url : http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040203/8e527a06/attachment-0002.obj From unreal at home.nl Tue Feb 3 00:23:43 2004 From: unreal at home.nl (Michel) Date: Tue, 3 Feb 2004 00:23:43 +0100 Subject: [En-Nut-Discussion] PPP fixes Message-ID: <006001c3e9e3$99365a70$6400a8c0@imhotep> And this time with the correct files.... > -----Original Message----- > From: Michel [mailto:unreal at home.nl] > Sent: dinsdag 3 februari 2004 0:12 > To: 'Ethernut User Chat (English)' > Subject: PPP fixes > > > Hi all, > > As promised, here are my fixes for PPP. Sorry it took so long :-) > > The last fixes I posted did not fix the case where an option > that was rejected was longer than the option just in the front of it. > > Basically what I did was fix the CONFREJ by moving all remaining > options to the front of the packet, not just the one being rejected. > > In NutLcpInput() and in NutPapInput() I also made a small > improvement by setting the size of the network layer > (nb_nw.sz) to the correct value. Although this didn't seem to > be harmfull in any way, maybe it will prevent any future problems. > > These fixes have enabled me to succesfully dialin to some of > the larger Dutch ISP's. > > To my regret, I noticed that I missed the closing date for an > official release by just a few days. Ah well, better luck > next time :-) > > Greetings > > Michel Hendriks > -------------- next part -------------- A non-text attachment was scrubbed... Name: ppp.zip Type: application/octet-stream Size: 10515 bytes Desc: not available Url : http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040203/3b627b52/attachment.obj From harald.kipp at egnite.de Tue Feb 3 10:12:03 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 03 Feb 2004 10:12:03 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: References: <5.1.1.6.0.20040202120557.03268890@egnite.de> <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040202120557.03268890@egnite.de> Message-ID: <5.1.1.6.0.20040203095334.03223460@egnite.de> Hi Kolja, At 23:38 02.02.2004 +0100, you wrote: >Hi, > > > >http://www.OCDemon.com has GNU gcc 2.95.3+binutils+gdb/insight for ARM. > > Isn't 2.95 a little bit outdated? > >In principle, yes. But unless you find a toolchain using 3.3 or 3.4 that isn't >tagged "experimental", I'd recommend staying with 2.95.3. Especially if C++ >isn't needed but just C and assembler. Good argument. >I agree that something like a WinAVR package for ARM would be really nice. >However, I'm quite sure it wouldn't be a "WinARM" but rather a "WinAT91" or >"WinLPC2X": > >"ARM" just isn't a synonym for some well-defined platform like "AVR" is. Right, and it would be no big deal to provide one or more linker scripts or similar configs, specifically designed for a few reference platforms. As long as we do not force everyone building a complete toolchain on Cygwin. > > We selected the AT91R40008 for the first step. > > [...] > > internal RAM is the killer argument. > >Probably it is wise to restrict ARM support in Nut/OS to platforms/CPUs that >have something like this in common: no need for Megabytes of RAM nor ROM. > >From my point of view, Nut/OS can provide an environment with threads and >TCP/IP for targets with small memory. Anyone who has a "bigger" target could >use uClinux or eCos or KADAK or ... My view as well. But there I received requests for larger Xscale CPUs too. The idea is, that they need a very fast CPU for a simple multimedia application but don't want to handle a large OS. But these are rare cases, I assume. >Beside some Atmel CPUs, I'd like to see Philips LPC21xx supported. Yet they >aren't available with external bus, but it is supposed to change soon. Even >without external bus, having a TCP/IP stack can be useful with PPP etc... Yes, Erik Lins also pointed me to these CPUs. >on a ZyXEL router I happen to own (with Samsung S3C4510 CPU with ARM7TDMI). :-) My family bought me a Gameboy Advanced as a Christmas present. After SimCity became boring, I'm wondering now, if I can get Nut/OS running on it. Harald From harald.kipp at egnite.de Tue Feb 3 09:50:33 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 03 Feb 2004 09:50:33 +0100 Subject: [En-Nut-Discussion] Makefile automagic In-Reply-To: <000201c3e9d2$80a05120$1601a8c0@p3> References: <000001c3e9d1$7991f0b0$1601a8c0@p3> Message-ID: <5.1.1.6.0.20040203094545.03225eb0@egnite.de> Lars, yeah, that's a funny thing and many users, including me, had been looking for this line in the Makefiles. In fact it isn't there. Make finds out, that it needs to create this file to build the final binary. But because it never appears on the final target list (unless you follow Marc's advice, entering 'make httpd.elf'), make deletes it after the binary is done. Or add it to the 'all' list in the Makefile. Harald At 22:21 02.02.2004 +0100, you wrote: >Hi group, > >Somewhere in the Make process >this command line is generated > >rm httpd.elf > >can I suppress this in some way? >I just can't find where it happens! From harald.kipp at egnite.de Tue Feb 3 10:19:08 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 03 Feb 2004 10:19:08 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <01ec01c3e9de$37fdb050$2301a8c0@Mike> References: <5.1.1.6.0.20040202112338.031f81d8@egnite.de> Message-ID: <5.1.1.6.0.20040203101607.01b9baa8@egnite.de> Mike, At 09:45 03.02.2004 +1100, you wrote: >Jan got in before me but I will second his sugestion. I'm convinced. You and Jan are the experts and no alternative has been suggested here. So we should go with http://www.kpitgnutools.com for the H8. Thanks, Harald From harald.kipp at egnite.de Tue Feb 3 10:35:54 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 03 Feb 2004 10:35:54 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <1075793562.401f4e9aaf19e@tiger.enttec> References: <00d201c3ea24$3748dc70$0205a8c0@hugin> <00d201c3ea24$3748dc70$0205a8c0@hugin> Message-ID: <5.1.1.6.0.20040203102115.01bb4fe8@egnite.de> Nic, At 18:32 03.02.2004 +1100, you wrote: >This one looks really good. But I suspect they have used the standard newlib, >which needs to be hacked and rebuilt because the crt0.s file relies >heavily on >the ARM monitor (HaL I think). >Harald I'm not sure you will be able to find an prebuilt toolchain for ARM >that >is as clean as Winavr. But this should not stop development on a Ethernut >4 ARM. No, of course not. I want to make sure, that as many people as possible can participate, no matter what their skills in configuring and building toolchains are or what kind of development environment they prefer. Many Nut/OS users are hardware freaks with limited software knowledge. May be, someone can setup a pre-build toolchain for a specific target platform and contribute it for download as a first, temporary step. Harald P.S. Personally I'll use Atmel's AT91EB40A Kit until my company designs a new Ethernut. From damian at commtech.com.au Tue Feb 3 13:59:55 2004 From: damian at commtech.com.au (Damian Slee) Date: Tue, 3 Feb 2004 20:59:55 +0800 Subject: [En-Nut-Discussion] Supporting Other Target Platforms Message-ID: i'd agree with the Atmel EB40A development board. It has the AT91R40008 with 256K ram on board and 2M flash external. The AT91FR40162 appears to be a copy of the AT92R40008 but with the 2M flash on chip. BGA package. Makes for a really really small design. However the Samsung one mentioned earlier with onboard LAN I have seen in the Linksys access points. But external flash and ram. -----Original Message----- From: Harald Kipp [mailto:harald.kipp at egnite.de] Sent: Tue 3/02/2004 5:35 PM To: Ethernut User Chat (English) Cc: Subject: RE: [En-Nut-Discussion] Supporting Other Target Platforms Nic, At 18:32 03.02.2004 +1100, you wrote: >This one looks really good. But I suspect they have used the standard newlib, >which needs to be hacked and rebuilt because the crt0.s file relies >heavily on >the ARM monitor (HaL I think). >Harald I'm not sure you will be able to find an prebuilt toolchain for ARM >that >is as clean as Winavr. But this should not stop development on a Ethernut >4 ARM. No, of course not. I want to make sure, that as many people as possible can participate, no matter what their skills in configuring and building toolchains are or what kind of development environment they prefer. Many Nut/OS users are hardware freaks with limited software knowledge. May be, someone can setup a pre-build toolchain for a specific target platform and contribute it for download as a first, temporary step. Harald P.S. Personally I'll use Atmel's AT91EB40A Kit until my company designs a new Ethernut. _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 5330 bytes Desc: not available Url : http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040203/954fb5d5/attachment.bin From harald.kipp at egnite.de Tue Feb 3 14:20:49 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 03 Feb 2004 14:20:49 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: Message-ID: <5.1.1.6.0.20040203141458.03303cf8@egnite.de> Damian, At 20:59 03.02.2004 +0800, you wrote: >The AT91FR40162 appears to be a copy of the AT92R40008 but with the 2M >flash on chip. BGA package. Makes for a really really small design. As far as I know this is a two die chip. Might be expensive. > >However the Samsung one mentioned earlier with onboard LAN I have seen in >the Linksys access points. But external flash and ram. Be aware that most of the onboard LANs are MAC only, no PHY. Harald From harald.kipp at egnite.de Tue Feb 3 14:30:30 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 03 Feb 2004 14:30:30 +0100 Subject: [En-Nut-Discussion] Question about two network connections. In-Reply-To: <00bc01c3e99c$bcfdb760$1101000a@Alex> Message-ID: <5.1.1.6.0.20040203142124.032c5838@egnite.de> Hi Alexander, This may be caused by many bugs. The system itself seems to be stable in this sense...but who knows. Recently a bug in netbuf.c had been detected, but it appears under very specific circumstances only. May be try a copy of this file from CVS. In the first place increase the stack size of your threads. This is easy. Next, carefully review your code, specially those parts, that write to allocated memory. The malloc routines in the debug version (NUTDEBUG) offer some additional protection and may help to locate the problem. If two threads are modifying multibyte values, make sure, that the modification is atomic. Most likely the problem is _not_ caused by too less heap space. Harald At 09:56 02.02.2004 -0500, you wrote: >Hi, All. >I have such a problem: >I use two network oriented threads. >Main thread periodically sends data through Inet using POST method of http >protocol. Having sent the next potion of data, it obtains something as >server reply and parses it as server command. >Another thread, which I call DirectTCP, opens another socket and accepts >data from port 23 - telnet like this: >NutTcpAccept(dirsock, 23). >It is supposed to be used for immediate incoming commands from the server. >Actually, it works but sometimes it hangs up and the box is being reloaded >by watchdog. I tried to investigate the situation and found that the >'tdp->td_memory' of the main thread after some time becomes not equal to >DEADBEEF, which is interpreted as "CORRUPT" in one of the examples. I tried >to free as much heap as possible and now I have almost 16K heap available, >but I have not achieved stable work still. >Maybe I have to upgrade the system? Judging from version.c I use 3.3.0.1. >now. Please, advise. >Thanks, >Alexander Baranov > >_______________________________________________ >En-Nut-Discussion mailing list >En-Nut-Discussion at egnite.de >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From conorduke at yahoo.co.uk Tue Feb 3 16:51:58 2004 From: conorduke at yahoo.co.uk (=?iso-8859-1?q?Conor=20Duke?=) Date: Tue, 3 Feb 2004 15:51:58 +0000 (GMT) Subject: [En-Nut-Discussion] undefined reference Message-ID: <20040203155158.92919.qmail@web25004.mail.ukl.yahoo.com> Dear Group , I tried recompliling my libraries but iu continually get the same error when i try to make this file the error is web808.o(.text+0x52): undefined reference to `devUsartAvr0' I can't seen to solve this bug,has any1 got any input? Regards Conor --------------------------------- Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040203/0694f395/attachment.html From harald.kipp at egnite.de Tue Feb 3 17:31:05 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 03 Feb 2004 17:31:05 +0100 Subject: [En-Nut-Discussion] PPP fixes In-Reply-To: <006001c3e9e3$99365a70$6400a8c0@imhotep> Message-ID: <5.1.1.6.0.20040203170408.0321e1a0@egnite.de> Hi Michel, > > As promised, here are my fixes for PPP. Sorry it took so long :-) No problem, but I fear it's too late for 3.4.1. We already spend two days on the tests and just finished the Windows installation. Linux installation is being build right now. Your patches make sense to me, but I needed some time to get into the code again. Sigh, this PPP stuff is really weird. I'll add your changes to HEAD and, after some additional connection tests, to 3.4.2. Many thanks for the good job, Harald From harald.kipp at egnite.de Tue Feb 3 17:33:39 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 03 Feb 2004 17:33:39 +0100 Subject: [En-Nut-Discussion] undefined reference In-Reply-To: <20040203155158.92919.qmail@web25004.mail.ukl.yahoo.com> Message-ID: <5.1.1.6.0.20040203173142.032203f8@egnite.de> Conor, Either your Makefile or your nut libraries aren't up to date. Make sure that usartavr0.c is being linked into libnutdev.a. Harald At 15:51 03.02.2004 +0000, you wrote: >Dear Group , >I tried recompliling my libraries but iu continually get the same error >when i try to make this file >the error is >web808.o(.text+0x52): undefined reference to `devUsartAvr0' >I can't seen to solve this bug,has any1 got any input? >Regards >Conor From Baranov at intech21.com Tue Feb 3 20:25:55 2004 From: Baranov at intech21.com (Alexander Baranov) Date: Tue, 3 Feb 2004 14:25:55 -0500 Subject: [En-Nut-Discussion] Question about two network connections. References: <5.1.1.6.0.20040203142124.032c5838@egnite.de> Message-ID: <004401c3ea8b$8b5800e0$1101000a@Alex> Thanks, Harald. I suspect that the size of stack is the point. Could you tell me how to increase the size of stack of main thread or give me the reference to the doc? I could not find it using context search. Regards, Alex. ----- Original Message ----- From: "Harald Kipp" To: "Ethernut User Chat (English)" Sent: Tuesday, February 03, 2004 8:30 AM Subject: Re: [En-Nut-Discussion] Question about two network connections. > Hi Alexander, > > This may be caused by many bugs. The system itself > seems to be stable in this sense...but who knows. > Recently a bug in netbuf.c had been detected, but > it appears under very specific circumstances only. > May be try a copy of this file from CVS. > > In the first place increase the stack size of > your threads. This is easy. > > Next, carefully review your code, specially those > parts, that write to allocated memory. The malloc > routines in the debug version (NUTDEBUG) offer > some additional protection and may help to locate > the problem. > > If two threads are modifying multibyte values, > make sure, that the modification is atomic. > > Most likely the problem is _not_ caused by too less > heap space. > > Harald > > > At 09:56 02.02.2004 -0500, you wrote: > >Hi, All. > >I have such a problem: > >I use two network oriented threads. > >Main thread periodically sends data through Inet using POST method of http > >protocol. Having sent the next potion of data, it obtains something as > >server reply and parses it as server command. > >Another thread, which I call DirectTCP, opens another socket and accepts > >data from port 23 - telnet like this: > >NutTcpAccept(dirsock, 23). > >It is supposed to be used for immediate incoming commands from the server. > >Actually, it works but sometimes it hangs up and the box is being reloaded > >by watchdog. I tried to investigate the situation and found that the > >'tdp->td_memory' of the main thread after some time becomes not equal to > >DEADBEEF, which is interpreted as "CORRUPT" in one of the examples. I tried > >to free as much heap as possible and now I have almost 16K heap available, > >but I have not achieved stable work still. > >Maybe I have to upgrade the system? Judging from version.c I use 3.3.0.1. > >now. Please, advise. > >Thanks, > >Alexander Baranov > > > >_______________________________________________ > >En-Nut-Discussion mailing list > >En-Nut-Discussion at egnite.de > >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From harald.kipp at egnite.de Tue Feb 3 21:46:30 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 03 Feb 2004 21:46:30 +0100 Subject: [En-Nut-Discussion] Nut/OS and ImageCraft Message-ID: <5.1.1.6.0.20040203214453.01b9fb78@egnite.de> Using ImageCraft C at http://www.ethernut.de/en/iccavr/index.html had been partly updated. This was really old stuff. Harald From Baranov at intech21.com Tue Feb 3 23:28:13 2004 From: Baranov at intech21.com (Alexander Baranov) Date: Tue, 3 Feb 2004 17:28:13 -0500 Subject: [En-Nut-Discussion] main thread stack size References: <5.1.1.6.0.20040203170408.0321e1a0@egnite.de> Message-ID: <000901c3eaa5$02cf2860$1101000a@Alex> Harald, thanks once more. I found the place and increased the stack size. Now it seems to work. Alex ----- Original Message ----- From: "Harald Kipp" To: "Ethernut User Chat (English)" Sent: Tuesday, February 03, 2004 11:31 AM Subject: Re: [En-Nut-Discussion] PPP fixes > Hi Michel, > > > > > As promised, here are my fixes for PPP. Sorry it took so long :-) > > No problem, but I fear it's too late for 3.4.1. We already > spend two days on the tests and just finished the Windows > installation. Linux installation is being build right now. > > Your patches make sense to me, but I needed some time to > get into the code again. Sigh, this PPP stuff is really > weird. > > I'll add your changes to HEAD and, after some additional > connection tests, to 3.4.2. > > Many thanks for the good job, > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From damian at commtech.com.au Wed Feb 4 01:57:52 2004 From: damian at commtech.com.au (Damian Slee) Date: Wed, 4 Feb 2004 08:57:52 +0800 Subject: [En-Nut-Discussion] Supporting Other Target Platforms Message-ID: About US$15.43 at www.digikey.com for 100 price break. About $2-$4 more than the Mega128. That's about 20% more cost for a lot more powerfull uC. Caught the eye of our electronics engineer some month back. Sounded good to me. In Australia; Budgetary Info AT91FR40162-CI Price: USD$17.50 MOQ 83 pcs rounded up to nearest packsize. Pack Qty: TBC Lead time 10-12 wks ARO -----Original Message----- From: Harald Kipp [mailto:harald.kipp at egnite.de] Sent: Tuesday, 3 February 2004 9:21 PM To: Ethernut User Chat (English) Subject: RE: [En-Nut-Discussion] Supporting Other Target Platforms Damian, At 20:59 03.02.2004 +0800, you wrote: >The AT91FR40162 appears to be a copy of the AT92R40008 but with the 2M >flash on chip. BGA package. Makes for a really really small design. As far as I know this is a two die chip. Might be expensive. > >However the Samsung one mentioned earlier with onboard LAN I have seen >in the Linksys access points. But external flash and ram. Be aware that most of the onboard LANs are MAC only, no PHY. Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From ralph.mason at telogis.com Wed Feb 4 17:14:55 2004 From: ralph.mason at telogis.com (Ralph Mason) Date: Thu, 05 Feb 2004 05:14:55 +1300 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <5.1.1.6.0.20040203141458.03303cf8@egnite.de> References: <5.1.1.6.0.20040203141458.03303cf8@egnite.de> Message-ID: <40211A7F.3090000@telogis.com> I like the look of the OKI chips http://www.okisemi.com/jp/english/ml674k.htm I was quoted $8.86US on the ML67Q4002TC in lots of 60 and $10.45 US on the ML67Q4003TC http://www.okisemi.com/jp/english/arm-strt.htm. There is also a step up from there to a faster chip in the same package. They read very much like a big AVR, (but cost less than one). The look like quite a natural progression and fit on an AVR board. Ralph > Damian, > > At 20:59 03.02.2004 +0800, you wrote: > >> The AT91FR40162 appears to be a copy of the AT92R40008 but with the >> 2M flash on chip. BGA package. Makes for a really really small design. > > > As far as I know this is a two die chip. Might > be expensive. > > >> >> However the Samsung one mentioned earlier with onboard LAN I have >> seen in the Linksys access points. But external flash and ram. > > > Be aware that most of the onboard LANs are MAC > only, no PHY. > > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > -- NOTICE: This message (including any attachments) contains CONFIDENTIAL INFORMATION intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. From tgeffers at web.de Wed Feb 4 18:25:45 2004 From: tgeffers at web.de (Geffers, Thorsten) Date: Wed, 4 Feb 2004 18:25:45 +0100 Subject: [En-Nut-Discussion] General PPP Question Message-ID: <000001c3eb43$ed905060$9699a8c0@Notebook> Hi @all! Maybe this isn't exactly an ethernut question, but I think (and hope) someone can help me! I have a PPP implementation that works well with a German ISP. After the PAP Ack the ISP sends an IPCP Request and everything works fine. Then I tested it via GPRS and an GPRS provider. This provider seems to wait for the client to send an IPCP Request. Does everybody now if it's right that some ISP send an IPCP Request and others wait for the client to do so?? And if it's true, how can software handle it? Because if both sides send requests, it seems that there will be no end with the IPCP phase. Thank you for your help!! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040204/e51dfdbf/attachment.htm From c.a.m at blueyonder.co.uk Wed Feb 4 19:11:05 2004 From: c.a.m at blueyonder.co.uk (c.a.m at blueyonder.co.uk) Date: Wed, 04 Feb 2004 18:11:05 +0000 Subject: [En-Nut-Discussion] General PPP Question In-Reply-To: <000001c3eb43$ed905060$9699a8c0@Notebook> References: <000001c3eb43$ed905060$9699a8c0@Notebook> Message-ID: On Wed, 4 Feb 2004 18:25:45 +0100, you wrote: >Hi @all! > >Maybe this isn't exactly an ethernut question, but I think (and hope) >someone can help me! > >I have a PPP implementation that works well with a German ISP. After the >PAP Ack the ISP >sends an IPCP Request and everything works fine. > >Then I tested it via GPRS and an GPRS provider. This provider seems to >wait for the client >to send an IPCP Request. > >Does everybody now if it's right that some ISP send an IPCP Request and >others wait for the >client to do so?? And if it's true, how can software handle it? Because >if both sides send requests, >it seems that there will be no end with the IPCP phase. Well, the way I see it, is that you send your request no matter what (after both sides have accepted each others LCP options), with your ip entries set to 0.0.0.0 (unless you are using fixed ip's). I spent quite some time writing a complete PPP routine etc (it's on the AVR freaks site in the projects area - ppp.zip). So far, it works flawlessly on a windows ppp server, BY and NTL ISP's via dial up modem, and on the vodaphone and orange networks via gprs here in the UK. As soon as the LCP options are done with, I send an immediate IPCP request with the 3 ip's set to 0.0.0.0 ... whether they send their IPCP first makes no odd's really, you just rej the compression option to start with (if you don't use compression), and ack the ip option they send (the next time they send their request). As with the LCP options, the negotiations are separate (each end), and it doesn't matter who sends the first request. Lexxy From dferbas at dfsoft.cz Thu Feb 5 00:08:57 2004 From: dferbas at dfsoft.cz (Dusan Ferbas) Date: Thu, 05 Feb 2004 00:08:57 +0100 Subject: [En-Nut-Discussion] General PPP Question In-Reply-To: <20040204172800.17FC22F42A7@p15095813.pureserver.info> References: <20040204172800.17FC22F42A7@p15095813.pureserver.info> Message-ID: <6.0.1.1.2.20040205000024.01af5780@pop3.servery.cz> Hi Geffers, as far as I know both sides should send IPCP requests because each side has to be assigned with an IP address. IP address can be 0.0.0.0 then it is a request for assignment from the other side. Nonzero address can be REJected or NAKed to negotiate. It can happen that both sides want to force their idea of IP address. In such a case PPP negotiation always fails. LCP negotiation can be initiated from one side. This is not true for IPCP. I assume that if you are connecting to an ISP you should send IPCP conf. req. and you should send it with 0.0.0.0, DNS1,2 0.0.0.0 options. >Date: Wed, 4 Feb 2004 18:25:45 +0100 >From: "Geffers, Thorsten" >Subject: [En-Nut-Discussion] General PPP Question > >Hi @all! > >Maybe this isn't exactly an ethernut question, but I think (and hope) >someone can help me! > >I have a PPP implementation that works well with a German ISP. After the >PAP Ack the ISP >sends an IPCP Request and everything works fine. > >Then I tested it via GPRS and an GPRS provider. This provider seems to >wait for the client >to send an IPCP Request. > >Does everybody now if it's right that some ISP send an IPCP Request and >others wait for the >client to do so?? And if it's true, how can software handle it? Because >if both sides send requests, >it seems that there will be no end with the IPCP phase. > Dusan From damian at commtech.com.au Thu Feb 5 03:07:58 2004 From: damian at commtech.com.au (Damian Slee) Date: Thu, 5 Feb 2004 10:07:58 +0800 Subject: [En-Nut-Discussion] Supporting Other Target Platforms Message-ID: Looks alright Ralph. Gets rid of the external RAM in the mega128 and a bit more code space. Do you used the ARM SDT C compiler that have listed there? I couldn't see anywhere to download it. Or GCC http://www.okisemi.com/jp/english/armsdt.htm If you like more ram/flash on chip, I still think the Atmel ones the way to go. -----Original Message----- From: Ralph Mason [mailto:ralph.mason at telogis.com] Sent: Thursday, 5 February 2004 12:15 AM To: Ethernut User Chat (English) Subject: Re: [En-Nut-Discussion] Supporting Other Target Platforms I like the look of the OKI chips http://www.okisemi.com/jp/english/ml674k.htm I was quoted $8.86US on the ML67Q4002TC in lots of 60 and $10.45 US on the ML67Q4003TC http://www.okisemi.com/jp/english/arm-strt.htm. There is also a step up from there to a faster chip in the same package. They read very much like a big AVR, (but cost less than one). The look like quite a natural progression and fit on an AVR board. Ralph > Damian, > > At 20:59 03.02.2004 +0800, you wrote: > >> The AT91FR40162 appears to be a copy of the AT92R40008 but with the >> 2M flash on chip. BGA package. Makes for a really really small design. > > > As far as I know this is a two die chip. Might be expensive. > > >> >> However the Samsung one mentioned earlier with onboard LAN I have >> seen in the Linksys access points. But external flash and ram. > > > Be aware that most of the onboard LANs are MAC > only, no PHY. > > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > -- NOTICE: This message (including any attachments) contains CONFIDENTIAL INFORMATION intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From ngbmoreau at yahoo.com.au Thu Feb 5 06:00:53 2004 From: ngbmoreau at yahoo.com.au (NGB) Date: Thu, 5 Feb 2004 16:00:53 +1100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: References: Message-ID: <1075957253.4021ce05e8138@tiger.enttec> I'd be a bit worried about OKI chips, for the people who are in a supplier black hole like Australia. It's very hard to get our hands on these chips. Atmel on the other hand is readily availabe, support is easy to get too, If this is to become Ethernut 3, I'd strongly recommend staying with a mainstream / low volume manufacturer my 2 cents Nic Quoting Damian Slee : > Looks alright Ralph. Gets rid of the external RAM in the mega128 and a > bit more code space. > Do you used the ARM SDT C compiler that have listed there? I couldn't > see anywhere to download it. Or GCC > http://www.okisemi.com/jp/english/armsdt.htm > > > If you like more ram/flash on chip, I still think the Atmel ones the way > to go. > ------------------------------------------------- From damian at commtech.com.au Thu Feb 5 06:28:01 2004 From: damian at commtech.com.au (Damian Slee) Date: Thu, 5 Feb 2004 13:28:01 +0800 Subject: [En-Nut-Discussion] Supporting Other Target Platforms Message-ID: Have to agree with that. We couldn't get any mega32's here. Got them through our US office in a couple of weeks. -----Original Message----- From: NGB [mailto:ngbmoreau at yahoo.com.au] Sent: Thursday, 5 February 2004 1:01 PM To: Ethernut User Chat (English) Subject: RE: [En-Nut-Discussion] Supporting Other Target Platforms I'd be a bit worried about OKI chips, for the people who are in a supplier black hole like Australia. It's very hard to get our hands on these chips. Atmel on the other hand is readily availabe, support is easy to get too, If this is to become Ethernut 3, I'd strongly recommend staying with a mainstream / low volume manufacturer my 2 cents Nic Quoting Damian Slee : > Looks alright Ralph. Gets rid of the external RAM in the mega128 and a > bit more code space. > Do you used the ARM SDT C compiler that have listed there? I couldn't > see anywhere to download it. Or GCC > http://www.okisemi.com/jp/english/armsdt.htm > > > If you like more ram/flash on chip, I still think the Atmel ones the > way to go. > ------------------------------------------------- _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From erik at lins.de Thu Feb 5 08:18:36 2004 From: erik at lins.de (Erik Lins) Date: Thu, 5 Feb 2004 08:18:36 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms Message-ID: <200402050718.i157IaK03152@web08.manitu.net> Hi, are there some other people who would be interested in a ColdFire port of Nut/OS? The MCF5282 is a cute part (64k SRAM, 512k Flash, lots of peripherals like UART,SPI,I2C,CAN,ADC and Ethernet MAC, external Bus available). Nut/OS would run without external memory, the only thing needed would be the ethernet Phy. I started setting up a suitable GNU toolchain on Cygwin and would provide binaries for download on my homepage on request. I also started a hardware project based on that ColdFire, which could be a basis for porting. Alternatively I would use my ColdFire Evalboard (http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D4888% 2526CCD%253DUSA%2526SID%253D4746%2526DID%253DDF2%2526SRT%253D1%2526LID% 253D0%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html). Who the hell needs such ugly URLs??? Cheers, ER!K --- LINS Technologies http://www.lins.de From ralph.mason at telogis.com Thu Feb 5 08:47:55 2004 From: ralph.mason at telogis.com (Ralph Mason) Date: Thu, 05 Feb 2004 20:47:55 +1300 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: References: Message-ID: <4021F52B.2000808@telogis.com> Damian Slee wrote: >Looks alright Ralph. Gets rid of the external RAM in the mega128 and a >bit more code space. >Do you used the ARM SDT C compiler that have listed there? I couldn't >see anywhere to download it. Or GCC >http://www.okisemi.com/jp/english/armsdt.htm > > >If you like more ram/flash on chip, I still think the Atmel ones the way >to go. > > > An 8mb dram is only a couple of dollars, there is no way you will approach 8mb ram and 512kb flash for $12 from atmel. For another $3 you can add a couple mb more flash. There are 4 chip selects so it's nice and easy to connect a few items to the bus. I think I will use GCC with it ( I am planing on doing something with it in the milddle of the year). Ralph From harald.kipp at egnite.de Thu Feb 5 11:26:55 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Thu, 05 Feb 2004 11:26:55 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <4021F52B.2000808@telogis.com> References: Message-ID: <5.1.1.6.0.20040205105833.031cf3e0@egnite.de> Ralph, >An 8mb dram is only a couple of dollars, there is no way you will approach >8mb ram and 512kb flash for $12 from atmel. For another $3 you can add a >couple mb more flash. There are 4 chip selects so it's nice and easy to >connect a few items to the bus. I'm afraid, that it's not that simple. As far as I understood, the low cost thumbs are running with 32 bit access in internal memory only. Having Nut/OS and the application in on-chip RAM is an advantage. Another thing is, that total cost is also based on chip count and PCB size. On the other hand, external flash gives more flexibility. It may contain the image _plus_ a file system. Harald From ngbmoreau at yahoo.com.au Thu Feb 5 11:31:01 2004 From: ngbmoreau at yahoo.com.au (NGB) Date: Thu, 5 Feb 2004 21:31:01 +1100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <200402050718.i157IaK03152@web08.manitu.net> References: <200402050718.i157IaK03152@web08.manitu.net> Message-ID: <1075977061.40221b657625d@localhost:2000> Watch out, this will start a processor war :-) I know the motorola cpus have some great features but: 1-AVR's are quite close to ARM cores 2-You will get a lot more out of an ARM port because of the number of processors available from different vendors. 3-You can easily upgrade to better cores eg: ARM9 I hope this makes sense. Nic Quoting Erik Lins : > Hi, > > are there some other people who would be interested in a ColdFire port > of Nut/OS? The MCF5282 is a cute part (64k SRAM, 512k Flash, lots of > peripherals like UART,SPI,I2C,CAN,ADC and Ethernet MAC, external Bus > available). Nut/OS would run without external memory, the only thing > needed would be the ethernet Phy. ------------------------------------------------- From harald.kipp at egnite.de Thu Feb 5 12:20:58 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Thu, 05 Feb 2004 12:20:58 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <1075957253.4021ce05e8138@tiger.enttec> References: Message-ID: <5.1.1.6.0.20040205112922.031d2b68@egnite.de> Hi Nic and others, At 16:00 05.02.2004 +1100, you wrote: >I'd be a bit worried about OKI chips, for the people who are in a supplier >black >hole like Australia. It's very hard to get our hands on these chips. >Atmel on the other hand is readily availabe, support is easy to get too, >If this is to become Ethernut 3, I'd strongly recommend staying with a >mainstream / low volume manufacturer > >my 2 cents > >Nic I'll take the chance to answer in a more general way. egnite will not be able to design and produce Ethernut hardware for all CPU flavors. We hope, that more hardware vendors will offer low level Ethernet enabled boards and support Nut/OS. That strategy may look stupid to our revenue oriented business, but only on the first look. I strongly believe, that if more people become involved, our company will benefit in the end. Charon II from http://www.hw.cz/ is a good alternative and we will put more effort into it's support. Hopefully Jan can get its production quantities up. http://www.lins.de/ has started with a Coldfire design. I wish he will get more response from this list than last time. Nevertheless, new hardware is coming from us. Mid of this month we will have the first series of Ethernut 2.zip, an ATmega128 - LAN91C111 - 32 kByte RAM module with PLCC-84 form factor. After this we will immediately start with an Ethernut 3 reference design, based on ARM. Like with Ethernut 2, we will publish early layouts and will be open to discuss them. This mailing list previously "forced" us, to put a CPLD on Ethernut 2, which was a very good decision. And I agree with you, that it is most important to use easy to get parts for Ethernut 3 to attract potential users. OKI is indeed a bit difficult, as they mainly produce these chips for their own use. Last, we consider to change the PCB format to something more flexibel. Don't panic, Ethernut 1/2 will be kept unchanged :-) Harald From zodianet at wanadoo.fr Thu Feb 5 12:42:44 2004 From: zodianet at wanadoo.fr (Zodianet) Date: Thu, 5 Feb 2004 12:42:44 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <5.1.1.6.0.20040205105833.031cf3e0@egnite.de> Message-ID: <20040205114446.54C43400917@mwinf0301.wanadoo.fr> I am not sure that Nut/OS needs a great "CPU upsizing" today but it needs to become first more reliable before migrate! Other bigger OS are in place and could be a better choice for bigger CPUs to fill quickly 512K of Flash ;-). Jean Pierre -----Message d'origine----- De : en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de] De la part de Harald Kipp Envoy? : jeudi 5 f?vrier 2004 11:27 ? : Ethernut User Chat (English) Objet : Re: [En-Nut-Discussion] Supporting Other Target Platforms Ralph, >An 8mb dram is only a couple of dollars, there is no way you will >approach 8mb ram and 512kb flash for $12 from atmel. For another $3 >you can add a couple mb more flash. There are 4 chip selects so it's >nice and easy to connect a few items to the bus. I'm afraid, that it's not that simple. As far as I understood, the low cost thumbs are running with 32 bit access in internal memory only. Having Nut/OS and the application in on-chip RAM is an advantage. Another thing is, that total cost is also based on chip count and PCB size. On the other hand, external flash gives more flexibility. It may contain the image _plus_ a file system. Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From ralph.mason at telogis.com Fri Feb 6 12:59:58 2004 From: ralph.mason at telogis.com (Ralph Mason) Date: Sat, 07 Feb 2004 00:59:58 +1300 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <5.1.1.6.0.20040205105833.031cf3e0@egnite.de> References: <5.1.1.6.0.20040205105833.031cf3e0@egnite.de> Message-ID: <402381BE.4070605@telogis.com> Harald Kipp wrote >> An 8mb dram is only a couple of dollars, there is no way you will >> approach 8mb ram and 512kb flash for $12 from atmel. For another $3 >> you can add a couple mb more flash. There are 4 chip selects so >> it's nice and easy to connect a few items to the bus. > > > I'm afraid, that it's not that simple. As far as I > understood, the low cost thumbs are running with > 32 bit access in internal memory only. Having Nut/OS > and the application in on-chip RAM is an advantage. But running thumb from 16 bit memory is optimal. It's all a question of what the goal is. To me it's more performance ( to allow simpler programing) with no more cost. > > Another thing is, that total cost is also based on chip > count and PCB size. And this one is nice, dram uses very few lines, the chip is in a 2cm X 2cm qfp package. Sounds like a 2 layer board to me. Clearly less than a atmega, a cpld and sram. > On the other hand, external flash gives more flexibility. > It may contain the image _plus_ a file system. Nand flash is always cheaper for a file system (and I have a nut compatible nand flash file system almost ready to release!) I guess at the end of the day, what is NutOS trying to be? Is it a new ecos in the making? Does it (Do we?) support process loading? What about AVR's - does it get so heavy as to leave them behind? Interesting article in Linux world this month - about open source trying to compete with itself (http://www.linuxworld.com/magazine/?issueid=352&de=1) Ralph From 021243 at student.hit.no Fri Feb 6 14:12:42 2004 From: 021243 at student.hit.no (Sigurd Kleppan) Date: Fri, 06 Feb 2004 14:12:42 +0100 Subject: [En-Nut-Discussion] Pin I/O Message-ID: I know how to set output pins. outp(0xff,PORTA); In this commando you have to set all 8 pins in one operation. I only want to set one pin without setting the other 7 pins. Can i do this with following commandos? If this is possible, how to i find the unique adress of each pin? By the way, do NUT/OS have some commando to send serial word through the I/O ports? This is a code i have found used by a another microcontroller. The code is used to get a temperature from DS1620. //Setting adress of the pins sbit RST = 0xA2; /* DS1620 reset line */ sbit CLK = 0xA3; /* DS1620 clock line */ sbit DQ = 0xA4; /* DS1620 data line void Put1620byte(unsigned char m) { unsigned char k,b=1; RST=1; for (k=0; k<8; k++) { CLK=0; DQ = (m & b); /* Send bit to 1620 */ CLK=1; b=(b<<1); /* Setup to send next bit */ } return; } unsigned char Get1620byte( void ) { unsigned char j,k=0,b=1; k=0; b=1; for (j=0; j<8; j++) { CLK=0; if (DQ) k|=b; /* Read bit and or if = 1 */ CLK=1; b=(b<<1); /* Setup for next read and or */ } return k; } void main(){ RST=1; Put1620byte(0xAA); /* read temp command */ temp_and_half_bit = Get1620byte(); /* read 1st byte of temp */ sign_bit = Get1620byte(); /* read 2nd byte of temp */ RST=0; } From bbuenaobra at nip.upd.edu.ph Sat Feb 7 11:32:18 2004 From: bbuenaobra at nip.upd.edu.ph (Berns J. Buenaobra) Date: Sat, 7 Feb 2004 02:32:18 -0800 Subject: [En-Nut-Discussion] How to echo to CRT external EEPROM R/W Message-ID: <000101c3ed65$ad0dabe0$3a65a8c0@instru.nip.upd.edu.ph> Hello all: I know this is too much for graduate student to ask but I'm desperate to have my lab project go through the end objective. I need to somehow see in my computer screen (CRT) when I am able to write to EEPROM and/or read back from the computer screen via hyperlink on a HTTP webserver page to a CGI what I have just written to it. Any ideas? Where and how should I connect my Ethernut board to do just exactly this? What can be the building blocks needed from the supplied examples? Thank you for your time. 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 ************************************ From ceba at vabo.cz Sat Feb 7 12:22:32 2004 From: ceba at vabo.cz (Pavel Celeda) Date: 07 Feb 2004 12:22:32 +0100 Subject: [En-Nut-Discussion] Missing lib directory in 3.4.1rc1 Message-ID: <1076152951.2325.79.camel@hw.vabo.cz> Hi, today I checked out Nut release candidate 3.4.1rc1 from CVS cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/ethernut co -r nut-3_4-release nut and there is no lib/... directory available. with best regards Pavel From ethernut at objenv.com Sun Feb 8 01:42:38 2004 From: ethernut at objenv.com (Rich Wellner) Date: Sat, 07 Feb 2004 18:42:38 -0600 Subject: [En-Nut-Discussion] NutUdpSendTo problem In-Reply-To: <000001c3b9b3$cf7ce820$1601a8c0@p3> ("Lars Andersson"'s message of "Wed, 3 Dec 2003 16:40:41 +0100") References: <000001c3b9b3$cf7ce820$1601a8c0@p3> Message-ID: <87ptcq7669.fsf@objenv.com> I wonder if you guys can spot me doing something obviously wrong here. I call NutUdpSendTo and always get a -1 return. I see from the mail list archives that there was a buffer handling problem in NutUdpSendTo in the past, but I've checked my source and not only does this problem seem unrelated, but I have the patch for the buffer handling issue. If I change the dest ip to 207.252.251.233 and run ethereal on the dest node then I get 0 returns from NutUdpSendTo and the activity light on the ethernut lights up, but the packet is never seen at the destination. output: ip: 207.252.251.238 netmask: 255.255.255.248 gateway: 207.252.251.233 dest ip: 216.127.80.16 return: -1 return: -1 return: -1 Source: int main(void) { u_long baud = 115200; u_char i; u_long dest_addr; UDPSOCKET *udpsock; /* * Initialize the uart device. */ NutRegisterDevice(&devDebug0, 0, 0); freopen("uart0", "w", stdout); _ioctl(_fileno(stdout), UART_SETSPEED, &baud); NutSleep(200); printf("\n\nNut/OS %s HTTP Daemon...\n", NutVersionString()); #ifdef NUTDEBUG NutTraceTcp(stdout, 0); NutTraceOs(stdout, 0); NutTraceHeap(stdout, 0); NutTracePPP(stdout, 0); #endif /* * Register Ethernet controller. */ //if(NutRegisterDevice(&devSmsc111, 0, 0)) if (NutRegisterDevice(&devEth0, 0x8300, 5)) puts("Registering device failed"); /* * LAN configuration using EEPROM values or DHCP/ARP method. * If it fails, use fixed values. */ if (NutDhcpIfConfig("eth0", 0, 60000)) { u_char mac[] = { MYMAC }; u_long ip_addr = inet_addr(MYIP); u_long ip_mask = inet_addr(MYMASK); puts("EEPROM/DHCP/ARP config failed"); NutNetIfConfig("eth0", mac, ip_addr, ip_mask); } printf("ip: %s\n", inet_ntoa(confnet.cdn_ip_addr)); printf("netmask: %s\n", inet_ntoa(confnet.cdn_ip_mask)); printf("gateway: %s\n", inet_ntoa(confnet.cdn_gateway)); udpsock = NutUdpCreateSocket(0); dest_addr = inet_addr("216.127.80.16"); printf("dest ip: %s\n", inet_ntoa(dest_addr)); /* * We could do something useful here, like serving a watchdog. */ NutThreadSetPriority(254); for (;;) { printf("return: %d\n", NutUdpSendTo(udpsock, dest_addr, 2526, "test", 4)); NutSleep(1000); } } From fischermi at t-online.de Sun Feb 8 11:17:34 2004 From: fischermi at t-online.de (Michael Fischer) Date: Sun, 8 Feb 2004 11:17:34 +0100 Subject: [En-Nut-Discussion] Ethernut CF (WLAN) Interface Message-ID: Hello, I think you have read the last thread about the Ethernut IDE/CF Interface. The problem was (is) that the Netgear MA401 is using the WAIT signal. Therefore I have now a new prototype with a bigger Xilinx. All the signals are pass-through the CPLD. This has the effect that I can use it as a level shifter for 3.3 and 5.0 voltage. But the "problem" with the WAIT still exist. Now I emulate the bus access. That mean the CPLD have several register and use an address range of 4 bytes. To make a write access to the MA401 you must use the follwing source: /************************************************************/ /* WriteXXX */ /************************************************************/ static void WriteXXX (WORD wAddress, WORD wData, MEMORY_TYPE eIO) { /* * set ADDRESS */ ADDRESS_LOW_REG = LOBYTE(wAddress); ADDRESS_HIGH_REG = HIBYTE(wAddress); /* * set DATA */ DATA_LOW_REG = LOBYTE(wData); DATA_HIGH_REG = HIBYTE(wData); /* * set CE1, CE2 */ CTRL_REG = (CTRL_CE1 | CTRL_CE2 | CTRL_OE | CTRL_WE | CTRL_IORD | CTRL_IOWR | CTRL_DATA_OUT); /* * set WR/IOWR */ if (eIO == TYPE_MEM) { CTRL_REG = (CTRL_CE1 | CTRL_CE2 | CTRL_OE | CTRL_IORD | CTRL_IOWR | CTRL_DATA_OUT); } else { CTRL_REG = (CTRL_CE1 | CTRL_CE2 | CTRL_OE | CTRL_WE | CTRL_IORD | CTRL_DATA_OUT); } /* * check the WAIT signal */ //Do some code here /* * remove WR/IOWR */ CTRL_REG = (CTRL_CE1 | CTRL_CE2 | CTRL_OE | CTRL_WE | CTRL_IORD | CTRL_IOWR | CTRL_DATA_OUT); /* * remove CE1, CE2 */ CTRL_REG = ( CTRL_OE | CTRL_WE | CTRL_IORD | CTRL_IOWR); } But this takes to long, up to 1,5us for an access. How can we solve this problem now? 1. Use the old way, direct mem/io access to the card. But use the function XDIV of the CPU. Divide the clock down to 3Mhz and hope the card get no problem. This was my first try with the first prototype. 2. Build a state machine in the CPLD. Which handle the access. I can imagine the following procedure: The CF card is a 16bit card, therefore we need to access, like the same as the IDE interface. Write the high byte at the odd address, and after this the low byte at the even address. The CPLD latch the address and the data. The last write at the even address start the state machine in the CPLD. Now the CPLD will do the rest. To check if this access is ready, there must exist a ctrl register in the CPLD. We can read this ctrl-reg and if the access is ready, a bit it set. I hope this is faster than 1,5us. Now some words about the source: I use here the source from FreeBSD, with the 1,5us way. I can access the MA401 (It is the 5V PCMCIA card). I hope that in the next weeks it is possible to receive a packet over the air. Who can help to design the CPLD? It should be a Xilinx CPLD, because the software is free. And I use here the Xilinx WebPack 6.1. Best regards, Michael From harald.kipp at egnite.de Sun Feb 8 22:00:53 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Sun, 08 Feb 2004 22:00:53 +0100 Subject: [En-Nut-Discussion] test, please ignore Message-ID: <5.1.1.6.0.20040208220039.0322d3f8@egnite.de> From Douglas.Pearless at pearless.co.nz Sun Feb 8 22:25:15 2004 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Mon, 09 Feb 2004 10:25:15 +1300 Subject: [En-Nut-Discussion] Driving a daugther board from the EtherNut 2 In-Reply-To: <5.1.1.6.0.20040205112922.031d2b68@egnite.de> Message-ID: <20040208211926.E0693ADFE3@smtp-3.paradise.net.nz> Hi people, I am redesigning an EtherNut 1.3 daughter board to work with the newer EtherNut 2. The daughter board can draw at a peak, 5v up to 1.7 amps. In the past, the daughter board has a 5v 3A power supply that supplies the 5v to the EtherNut 1.3 (we remove the 5v regulator from the EtherNut) via the expansion header. Is it possible to upgrade the LM1086(1.5A) to a LM1085 (3A) or a LM1084(5A)? What else would need to change (F1 to 3A or 5A)? Would this work with the current board design (track width, vias etc)? I guess this will become more of an issue as more and more daughter / expansion boards are developed! The other alternative is to put a LM1084 on the daughter board, and removing the LM1086 from the EtherNut, which would not be my preference. Cheers Douglas --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.580 / Virus Database: 367 - Release Date: 6/02/2004 From Douglas.Pearless at pearless.co.nz Sun Feb 8 23:20:04 2004 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Mon, 09 Feb 2004 11:20:04 +1300 Subject: [En-Nut-Discussion] Complete newbie... In-Reply-To: <5.1.1.6.0.20030817111617.01a8d880@egnite.de> Message-ID: <20040208221415.C7D709E277@smtp-2.paradise.net.nz> As an aside, I was looking for information on the memory mapping of the EtherNut 2. This seems to be the only references I could find to the memory mapping in the mailing list and website. I assume that this is still current, and if I use 0xFE00-0xFEFF inclusive for a daughter board I have designed (it can be jumpered into any block as I decode A8-A15) that this will not cause a conflict? 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: Sunday, 17 August 2003 9:33 p.m. To: en-nut-discussion at egnite.de Subject: Re: [En-Nut-Discussion] Complete newbie... Radek, There's no limitation using any memory addresses from 0x8000 to 0x82FF and 0x8320 to 0xFFFF. May be there's some kind of address decoder timing problem, so that 0xE000 gets unintendently selected. How about adding delay cycles? More infos are given in the ATmega128 data sheet. Sure, there may be a bug in the software, but unlikely. Ethernut 2 uses all addresses upto 0xBFFF, the LAN91C111 is located at 0xC000 and the bank select register occupies 0xFF00 upto 0xFFFF. It uses the same software, just the NIC driver has been replaced. 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.510 / Virus Database: 307 - Release Date: 14/08/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.580 / Virus Database: 367 - Release Date: 6/02/2004 From Douglas.Pearless at pearless.co.nz Sun Feb 8 23:47:29 2004 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Mon, 09 Feb 2004 11:47:29 +1300 Subject: [En-Nut-Discussion] Ethernut 2 Message-ID: <20040208224141.493DC9E288@smtp-2.paradise.net.nz> Hi People, I am redesigning an EtherNut 1.3 daughter board (Quad UARTS, RS485/232/IrDA/Flash RAM, RTC clock/calendar, etc etc) to work with the newer EtherNut 2. As I am not sure my previous posting got through, I?d like to summarise my questions about the EtherNut 2: PE6 (INT6) is NOT used and can by used by my own design. Only RESET\ and not RESET goes to the expansion header (any plans to change this???) I can use 0xFE00 ? 0xFEFF to memory map my own design (if not, what ranges are available?). And lastly, the daughter board can draw at a peak, 5v up to 1.7 amps. In the past, the daughter board has a 5v 3A power supply that supplies the 5v to the EtherNut 1.3 via the expansion header (we remove the 5v regulator from the EtherNut). Is it possible to upgrade the LM1086(1.5A) to a LM1085 (3A) or a LM1084(5A)? What else would need to change (F1 to 3A or 5A)? Would this work with the current board design (track width, vias etc)? I guess this will become more of an issue as more and more daughter / expansion boards are developed! The other alternative is to put a LM1084 on the daughter board, and removing the LM1086 from the EtherNut, which would not be my preference. Cheers Douglas --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.580 / Virus Database: 367 - Release Date: 6/02/2004 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040209/a344b8aa/attachment.html From erik at lins.de Mon Feb 9 10:03:43 2004 From: erik at lins.de (Erik Lins) Date: Mon, 9 Feb 2004 10:03:43 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms Message-ID: <200402090903.i1993hV06165@web08.manitu.net> Dear Nic, > Watch out, this will start a processor war :-) uuh, I don't hope so! Everybody has it's favorate processor architecture and the reasons range from real technical issues over "we never used anything else" and end up to religious and fanatic reasons. I don't want to convince andbody to use ColdFire instead of ARM or whatever. > I know the motorola cpus have some great features but: > 1-AVR's are quite close to ARM cores That's correct and it might be an advantage during porting Nut/OS to the new architecture, but the advantage gets smaller when you program mostly in C/C++ and diminishes further when porting is done and you write native applications for the new CPU. > 2-You will get a lot more out of an ARM port because of the number of > processors available from different vendors. Well, that's a more "global" point of view, it might be true, that - well - "mankind" gets more out of an ARM port, but I have a certain demand for a ColdFire port, so in the near future _I_ will get more out of a ColdFire port. And since Harald takes care of an ARM port, both me and mankind should be satisfied in the end. ;-) The raw number of core implementations is not necessarily an indication for the quality of that core (I guess 8051 is on of the most often implemented cores and also one of the worst architectures humans ever invented, and also Intels x86 architecture is clearly deeply sub- optimal), but more an indication for the quality of some companies marketing division. > 3-You can easily upgrade to better cores eg: ARM9 Motorola (and to some extend IBM) offers ColdFire cores in various performance ranges (V2 core currently up to 125MHz, V4 core up to 316MHz) and the PowerPC based controllers (PowerQUICC network processors and MPCxxx microcontrollers) are some kind of elemental upgrade path ranging up to several hundred MHz. As my english teacher often mentioned: "Variety is the salt of life", so I think we should try to make Nut/OS available on several CPU architectures and I'm convinced that all ports will benefit from the work and experiences collected in certain ports, expecially non- mainstream ports in the end. Cheers, ER!K --- LINS Technologies http://www.lins.de From harald.kipp at egnite.de Mon Feb 9 11:06:25 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 09 Feb 2004 11:06:25 +0100 Subject: [En-Nut-Discussion] test Message-ID: <5.1.1.6.0.20040209110616.01c35488@egnite.de> test From Oliver.Schulz at bong.de Mon Feb 9 11:42:44 2004 From: Oliver.Schulz at bong.de (Oliver Schulz) Date: Mon, 9 Feb 2004 11:42:44 +0100 Subject: AW: [En-Nut-Discussion] NutUdpSendTo problem Message-ID: Hi Rich, > the patch for the buffer handling issue. If I change the dest ip to > 207.252.251.233 and run ethereal on the dest node then I get > 0 returns from So if use use an ip address of your LAN, the function returns 0. Looks like a routing problem. I discovered last weekend a small hidden bug in network interface configuring functions. If no DHCP is used (that is, if ethernut's ip address is set to a valid address during basemon), the gateway ip address is not added as default route, although it's properly configured in confnet struct. Rich, can you tell me, if you use DHCP for ethernut? Anyway, this evening I try to commit a bufgix for that in nut-3_4-release branch. Cheers, Oliver. From malte_rennert at web.de Mon Feb 9 13:59:54 2004 From: malte_rennert at web.de (Malte Rennert) Date: Mon, 9 Feb 2004 13:59:54 +0100 Subject: [En-Nut-Discussion] Ethernut CF (WLAN) Interface In-Reply-To: References: Message-ID: <200402091359.54813.malte_rennert@web.de> Am Sonntag, 8. Februar 2004 11:17 schrieb Michael Fischer: > Who can help to design the CPLD? > It should be a Xilinx CPLD, because the software is free. > And I use here the Xilinx WebPack 6.1. Hello Michael, maybe I can help to design the CPLD. I have some experiences with Xilinx Webpack. I used the XC95.. CPLDs and the XC2S50 FPGA. But I don't have any experiences with Ethernut right now. Please contact me if you need my help. Best regards Malte From francois at asnone.com Mon Feb 9 16:54:42 2004 From: francois at asnone.com (Francois Rademeyer) Date: Mon, 9 Feb 2004 17:54:42 +0200 Subject: [En-Nut-Discussion] GPRS PAP problem Message-ID: <01c101c3ef25$0a7a6e10$1000a8c0@sonyfrademeyer> Hi all, Firstly there seems to be a bug in the latest "lcpout.c" file. The line : if ((nb = NutNetBufAlloc(0, NBAF_APPLICATION, rejected ? 6 : 12)) != 0) { should be: if ((nb = NutNetBufAlloc(0, NBAF_APPLICATION, rejected ? 12 : 6)) != 0) { My real problem is that PAP authentication messages seem to be ignored by my GPRS server. The server requires a blank username and password. I have tried blank. I have tried passwords. I have even tried rejecting the (AUTH=0xC023) request from the server. Still I'm being ignored (except for the latter where I get a TERMREQ when it is time for IPCP negotiation). Has anyone experienced this? Could it be that the server is speechless without PCOMP and ACOMP? Thanks in advance for any help. Cheers, Francois Rademeyer Here is a shortened version of my PPP debug output for a blank id/password: PPP < [LCP-1 CONFREQ (ACCM = 0x000A000)] PPP > [LCP-1 CONFREQ (MRU=1500)(ACCM = 0x0000000)(PCOMP)(ACOMP)(AUTH=0xC023)] PPP < [LCP-1 CONFREJ (PCOMP)(ACOMP)] PPP > [LCP-1 CONFACK (ACCM = 0x000A000)] PPP > [LCP-2 CONFREQ (MRU=1500)(ACCM = 0x0000000)(AUTH=0xC023)] PPP < [LCP-2 CONFACK (MRU=1500)(ACCM = 0x0000000)(AUTH=0xC023)] PPP < [PAP-3 AUTHREQ] ... 5 second delay PPP < [PAP-3 AUTHREQ] ... 5 second delay PPP < [PAP-3 AUTHREQ] ... 5 second delay PPP < [PAP-3 AUTHREQ] ... 5 second delay PPP < [PAP-3 AUTHREQ] ... 5 second delay PPP < [PAP-3 AUTHREQ] ... no auth reply received (timeout) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040209/84e3e201/attachment.htm From Oliver.Schulz at bong.de Mon Feb 9 16:56:46 2004 From: Oliver.Schulz at bong.de (Oliver Schulz) Date: Mon, 9 Feb 2004 16:56:46 +0100 Subject: AW: [En-Nut-Discussion] Missing lib directory in 3.4.1rc1 Message-ID: Hi Pavel and all, although the directories are definitely in CVS, they are obviously not checked out. If running an CVS update with '-d' option (create missing subdirs) after the checkout, the missing directories are finally created. Harald, perhaps it is a good idea to place some dummy files in the lib subdirs, to ensure that these dirs will be created on CVS checkout.. Cheers, Oliver. > -----Urspr?ngliche Nachricht----- > Von: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von > Pavel Celeda > Gesendet: Samstag, 7. Februar 2004 12:23 > An: Ethernut User Chat (English) > Betreff: [En-Nut-Discussion] Missing lib directory in 3.4.1rc1 > > > Hi, > > today I checked out Nut release candidate 3.4.1rc1 from CVS > > cvs -z3 > -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/ethernut co -r > nut-3_4-release nut > > and there is no lib/... directory available. > > with best regards > Pavel > > > > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From ethernut at objenv.com Sun Feb 8 01:42:38 2004 From: ethernut at objenv.com (Rich Wellner) Date: Sat, 07 Feb 2004 18:42:38 -0600 Subject: [En-Nut-Discussion] NutUdpSendTo problem In-Reply-To: <000001c3b9b3$cf7ce820$1601a8c0@p3> ("Lars Andersson"'s message of "Wed, 3 Dec 2003 16:40:41 +0100") References: <000001c3b9b3$cf7ce820$1601a8c0@p3> Message-ID: <87ptcq7669.fsf@objenv.com> I wonder if you guys can spot me doing something obviously wrong here. I call NutUdpSendTo and always get a -1 return. I see from the mail list archives that there was a buffer handling problem in NutUdpSendTo in the past, but I've checked my source and not only does this problem seem unrelated, but I have the patch for the buffer handling issue. If I change the dest ip to 207.252.251.233 and run ethereal on the dest node then I get 0 returns from NutUdpSendTo and the activity light on the ethernut lights up, but the packet is never seen at the destination. output: ip: 207.252.251.238 netmask: 255.255.255.248 gateway: 207.252.251.233 dest ip: 216.127.80.16 return: -1 return: -1 return: -1 Source: int main(void) { u_long baud = 115200; u_char i; u_long dest_addr; UDPSOCKET *udpsock; /* * Initialize the uart device. */ NutRegisterDevice(&devDebug0, 0, 0); freopen("uart0", "w", stdout); _ioctl(_fileno(stdout), UART_SETSPEED, &baud); NutSleep(200); printf("\n\nNut/OS %s HTTP Daemon...\n", NutVersionString()); #ifdef NUTDEBUG NutTraceTcp(stdout, 0); NutTraceOs(stdout, 0); NutTraceHeap(stdout, 0); NutTracePPP(stdout, 0); #endif /* * Register Ethernet controller. */ //if(NutRegisterDevice(&devSmsc111, 0, 0)) if (NutRegisterDevice(&devEth0, 0x8300, 5)) puts("Registering device failed"); /* * LAN configuration using EEPROM values or DHCP/ARP method. * If it fails, use fixed values. */ if (NutDhcpIfConfig("eth0", 0, 60000)) { u_char mac[] = { MYMAC }; u_long ip_addr = inet_addr(MYIP); u_long ip_mask = inet_addr(MYMASK); puts("EEPROM/DHCP/ARP config failed"); NutNetIfConfig("eth0", mac, ip_addr, ip_mask); } printf("ip: %s\n", inet_ntoa(confnet.cdn_ip_addr)); printf("netmask: %s\n", inet_ntoa(confnet.cdn_ip_mask)); printf("gateway: %s\n", inet_ntoa(confnet.cdn_gateway)); udpsock = NutUdpCreateSocket(0); dest_addr = inet_addr("216.127.80.16"); printf("dest ip: %s\n", inet_ntoa(dest_addr)); /* * We could do something useful here, like serving a watchdog. */ NutThreadSetPriority(254); for (;;) { printf("return: %d\n", NutUdpSendTo(udpsock, dest_addr, 2526, "test", 4)); NutSleep(1000); } } From g.kindel at stud.hs-wismar.de Mon Feb 9 10:48:09 2004 From: g.kindel at stud.hs-wismar.de (oggi) Date: Mon, 9 Feb 2004 10:48:09 +0100 Subject: [En-Nut-Discussion] Getting remote ip address Message-ID: Hello, I have a problem, with getting a ip address from an remote host, the ethernut is a server and waiting for a connection, when a computer connect i need his ip to send him data back, but i don't know where i can get his ip. thanks for helping, and sorry about my bad english georg kindel =================================================================== EASY and FREE access to your email anywhere: http://Mailreader.com/ =================================================================== From harald.kipp at egnite.de Mon Feb 9 19:15:57 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 09 Feb 2004 19:15:57 +0100 Subject: [En-Nut-Discussion] Getting remote ip address In-Reply-To: Message-ID: <5.1.1.6.0.20040209190704.0329bd08@egnite.de> Hi Georg, Sorry it took some time to pull your post from a large queue after the list server crash. If you subribe at http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion your posts will appear in the list without approval. Regarding your _real_ problem: With TCP, you don't worry about the remote IP. You simply send data back on the same socket (same connection). See the tcps sample. For UDP, you'll get the remote address (and port) from NutUdpReceiveFrom(). Here's a simple snippet to give you an idea: u_long raddr; <--- Remote's IP u_short rport; <--- Remote's port for (;;) { if ((got = NutUdpReceiveFrom(sock, &raddr, &rport, buff, sizeof(buff), 1000)) <= 0) { printf("Recv failed\n"); } else { //printf("R%d-%s:%u\n", got, inet_ntoa(raddr), rport); if (NutUdpSendTo(sock, raddr, LOCALPORT, buff, got)) { printf("Send failed\n"); } else { putchar('S'); } } } Harald From Baranov at intech21.com Mon Feb 9 19:45:05 2004 From: Baranov at intech21.com (Alexander Baranov) Date: Mon, 9 Feb 2004 13:45:05 -0500 Subject: [En-Nut-Discussion] One more reference to PCB design Message-ID: <001a01c3ef3c$d5da36f0$1101000a@Alex> http://www.ti.informatik.uni-bonn.de/Extern/documents/highspeedboarddesign.pdf Alexander Baranov From harald.kipp at egnite.de Mon Feb 9 20:04:10 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 09 Feb 2004 20:04:10 +0100 Subject: [En-Nut-Discussion] Ethernut 2 In-Reply-To: <20040208224141.493DC9E288@smtp-2.paradise.net.nz> Message-ID: <5.1.1.6.0.20040209191758.031d4640@egnite.de> Hi Douglas, >I am redesigning an EtherNut 1.3 daughter board (Quad UARTS, >RS485/232/IrDA/Flash RAM, RTC clock/calendar, etc etc) to work with the >newer EtherNut 2. I've done everything to make this as painless as possible. >As I am not sure my previous posting got through, I d like to summarise my >questions about the EtherNut 2: The mailing list was down. Took a few days (and hints from kind people) to detect this problem. >PE6 (INT6) is NOT used and can by used by my own design. PE6 is not used. In fact, Ethernut 2 may use more Port Bits than Ethernut 1, but this is all optional and jumper selectable. >Only RESET\ and not RESET goes to the expansion header (any plans to >change this???) No, there are no plans to further change the Ethernut Expansion Connector. Take Ethernut 2 as final... OK, if we change this, there will be jumper. :-) >I can use 0xFE00 0xFEFF to memory map my own design (if not, what ranges >are available?). 0xFFXX is the bank select register. However, this is decoded in the CPLD and can be changed. I'll publish an Ethernut application to reprogram the CPLD soon. No need for a Xilinx JTAG adapter. Also the LAN91C111 address is decoded in the CPLD and thus changable. It currently located at 0xC000. We intentionally put the SMSC Controller at the beginning, so the upper regions are kept available for slower hardware. Remember, that the ATmega can specifically add memory cycles on upper regions. I'd suggest to use 0xDXXX for extension without waits and 0xEXXX for slow hardware. >And lastly, the daughter board can draw at a peak, 5v up to 1.7 amps. That's a lot. >In the past, the daughter board has a 5v 3A power supply that supplies the >5v to the EtherNut 1.3 via the expansion header (we remove the 5v >regulator from the EtherNut). Yes, the Ethernut 2 isn't still perfect. An additional diode bridging the 5V regulator would avoid to have it removed...sigh. But why not supply the DC pin with unregulated power (Expansion pin 10)? >Is it possible to upgrade the LM1086(1.5A) to a LM1085 (3A) or a LM1084(5A)? Sure, that was one reason why I chose this somewhat exotic regulator. However, your input voltage should be as low as possible, luckily LM108x are LDOs. 6.5V may already work, 7V is stable and fine. Using higher input voltages will produce a lot of heat with 1.7 Amps. And Ethernut 2 already becomes quite warm because of the 100 MBit controller. But the major problem are the traces and the rectifier bridge. Theoretically the unregulated DC trace width is sufficient for 1.85 Amps only, but they may already warm up. Worse, the rectifier takes 800 mA max. They are available for 1 Amp, but I do not know about any higher current. The 5V traces are no problem because Ethernut is a four layer board and has it's own supply layer, directly connected to the expansion port. >What else would need to change (F1 to 3A or 5A)? Right, the fuse needs to be changed. >Would this work with the current board design (track width, vias etc)? If there are just _peaks_ of 1.7 Amps, changing the regulator, replacing the fuse and shorterning the rectifier should work. But it depends on what you name peaks and how often they may occur or what's the average current. It's mainly a heat problem and thus depends on the environment. >I guess this will become more of an issue as more and more daughter / >expansion boards are developed! The few power hungry boards we designed got their own regulators and used the DC pin to supply Ethernut. This design has a better heat distribution. >The other alternative is to put a LM1084 on the daughter board, and >removing the LM1086 from the EtherNut, which would not be my preference. See above. Harald From harald.kipp at egnite.de Mon Feb 9 20:40:20 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 09 Feb 2004 20:40:20 +0100 Subject: [En-Nut-Discussion] NutUdpSendTo problem In-Reply-To: <87ptcq7669.fsf@objenv.com> References: <000001c3b9b3$cf7ce820$1601a8c0@p3> <000001c3b9b3$cf7ce820$1601a8c0@p3> Message-ID: <5.1.1.6.0.20040209201809.03238ae8@egnite.de> Hi Francois, At 18:42 07.02.2004 -0600, you wrote: >I wonder if you guys can spot me doing something obviously wrong here. I call >NutUdpSendTo and always get a -1 return. I see from the mail list archives >that there was a buffer handling problem in NutUdpSendTo in the past, but I've >checked my source and not only does this problem seem unrelated, but I have >the patch for the buffer handling issue. If I change the dest ip to >207.252.251.233 and run ethereal on the dest node then I get 0 returns from >NutUdpSendTo and the activity light on the ethernut lights up, but the packet >is never seen at the destination. Indeed. If 216.127.80.16 produces errors and 207.252.251.233 doesn't, then this is obviously no buffer problem. Frankly, I do not have the slightest idea, why Ethereal doesn't show the UDP packet on 207.252.251.233 after you set the destination to this IP. I have to admit too, that I never tried routing with with Ethernut's UDP, but, as routing is implemented in the IP layer and used by TCP too, I'm quite sure that this should work. I checked your network/netmask setup twice, but it looks OK to me. In your output EEPROM/DHCP/ARP config failed never appears, so you are using DHCP. May be there's the problem. Can you please try to use NutNetIfConfig("eth0", mac, ip_addr, ip_mask); NutIpRouteAdd(0, 0, inet_addr("207.252.251.233"), &devEth0); instead of NutDhcpIfConfig()? Still, Ethereal _must_ show something...at least the ARP request from Ethernut. Harald From harald.kipp at egnite.de Mon Feb 9 20:42:20 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 09 Feb 2004 20:42:20 +0100 Subject: [En-Nut-Discussion] NutUdpSendTo problem Message-ID: <5.1.1.6.0.20040209204134.031ff668@egnite.de> Oops, pardon me. Should have been Hi Rich, not Hi Francois, From harald.kipp at egnite.de Mon Feb 9 20:58:00 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 09 Feb 2004 20:58:00 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <20040205114446.54C43400917@mwinf0301.wanadoo.fr> References: <5.1.1.6.0.20040205105833.031cf3e0@egnite.de> Message-ID: <5.1.1.6.0.20040209204553.03227d50@egnite.de> Hi Jean Pierre, At 12:42 05.02.2004 +0100, you wrote: >I am not sure that Nut/OS needs a great "CPU upsizing" today but it needs to >become first more reliable before migrate! Do I detect hidden critics here? :-) Nut/OS will never be as reliable as larger systems, which offer MMU and protected memory regions. The cooperative threading adds additional traps. That's why it's more difficult to write reliable applications for Nut/OS compared to Linux. >Other bigger OS are in place and could be a better choice for bigger CPUs to >fill quickly 512K of Flash ;-). > For example, if you want to create an MP3 Ethernet player, you can use hardware. If you want to add Ogg Vorbis, you are lost (no idea, wether there are any hardware de/encoders available in the meantime, just to give an example). So you need raw power, but no eCos, Linux or whatever. Just something simple with a little bit TCP would do. That's at least my motivation. I'd like to see my GameBoy playing MPEG movies, which I transfered on it's CompactFlash card via FTP. Harald From Douglas.Pearless at pearless.co.nz Mon Feb 9 21:07:14 2004 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Tue, 10 Feb 2004 09:07:14 +1300 Subject: [En-Nut-Discussion] Ethernut 2 In-Reply-To: <5.1.1.6.0.20040209191758.031d4640@egnite.de> Message-ID: <20040209200124.6A66BADF66@smtp-3.paradise.net.nz> Hi Harald, Thanks for the input. In Summary: We will use: INT6 (PE6), 0xDXXX, power the EtherNut 2 from my daughter board (5v switch mode power supply to keep it cool). Note the 1.7A is for a specialised customer board (grand daughter board ;-) )that plugs into my daughter board as the daughter board itself on draws a few hundred mA. And lastly, we are looking to GPL the design, minus our customers commercially sensitive bit, I assume people would like a board that has these extra features? (we used the Oxford ox16c954, check out http://www.oxsemi.co.uk/download/standard/dsheets/ox16c954ds.pdf for more details on the chip itself) I notice that the template expansion board for the EtherNut 2 requires me to upgrade to Eagle v4.11, and changes of a version that I can open via Eagle 4.09? Cheer Douglas -----Original Message----- From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Harald Kipp Sent: Tuesday, 10 February 2004 8:04 a.m. To: Ethernut User Chat (English) Subject: Re: [En-Nut-Discussion] Ethernut 2 Hi Douglas, >I am redesigning an EtherNut 1.3 daughter board (Quad UARTS, >RS485/232/IrDA/Flash RAM, RTC clock/calendar, etc etc) to work with the >newer EtherNut 2. I've done everything to make this as painless as possible. >As I am not sure my previous posting got through, I d like to summarise my >questions about the EtherNut 2: The mailing list was down. Took a few days (and hints from kind people) to detect this problem. >PE6 (INT6) is NOT used and can by used by my own design. PE6 is not used. In fact, Ethernut 2 may use more Port Bits than Ethernut 1, but this is all optional and jumper selectable. >Only RESET\ and not RESET goes to the expansion header (any plans to >change this???) No, there are no plans to further change the Ethernut Expansion Connector. Take Ethernut 2 as final... OK, if we change this, there will be jumper. :-) >I can use 0xFE00 0xFEFF to memory map my own design (if not, what ranges >are available?). 0xFFXX is the bank select register. However, this is decoded in the CPLD and can be changed. I'll publish an Ethernut application to reprogram the CPLD soon. No need for a Xilinx JTAG adapter. Also the LAN91C111 address is decoded in the CPLD and thus changable. It currently located at 0xC000. We intentionally put the SMSC Controller at the beginning, so the upper regions are kept available for slower hardware. Remember, that the ATmega can specifically add memory cycles on upper regions. I'd suggest to use 0xDXXX for extension without waits and 0xEXXX for slow hardware. >And lastly, the daughter board can draw at a peak, 5v up to 1.7 amps. That's a lot. >In the past, the daughter board has a 5v 3A power supply that supplies the >5v to the EtherNut 1.3 via the expansion header (we remove the 5v >regulator from the EtherNut). Yes, the Ethernut 2 isn't still perfect. An additional diode bridging the 5V regulator would avoid to have it removed...sigh. But why not supply the DC pin with unregulated power (Expansion pin 10)? >Is it possible to upgrade the LM1086(1.5A) to a LM1085 (3A) or a LM1084(5A)? Sure, that was one reason why I chose this somewhat exotic regulator. However, your input voltage should be as low as possible, luckily LM108x are LDOs. 6.5V may already work, 7V is stable and fine. Using higher input voltages will produce a lot of heat with 1.7 Amps. And Ethernut 2 already becomes quite warm because of the 100 MBit controller. But the major problem are the traces and the rectifier bridge. Theoretically the unregulated DC trace width is sufficient for 1.85 Amps only, but they may already warm up. Worse, the rectifier takes 800 mA max. They are available for 1 Amp, but I do not know about any higher current. The 5V traces are no problem because Ethernut is a four layer board and has it's own supply layer, directly connected to the expansion port. >What else would need to change (F1 to 3A or 5A)? Right, the fuse needs to be changed. >Would this work with the current board design (track width, vias etc)? If there are just _peaks_ of 1.7 Amps, changing the regulator, replacing the fuse and shorterning the rectifier should work. But it depends on what you name peaks and how often they may occur or what's the average current. It's mainly a heat problem and thus depends on the environment. >I guess this will become more of an issue as more and more daughter / >expansion boards are developed! The few power hungry boards we designed got their own regulators and used the DC pin to supply Ethernut. This design has a better heat distribution. >The other alternative is to put a LM1084 on the daughter board, and >removing the LM1086 from the EtherNut, which would not be my preference. See above. Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.580 / Virus Database: 367 - Release Date: 6/02/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.580 / Virus Database: 367 - Release Date: 6/02/2004 From olischulz at web.de Mon Feb 9 21:31:59 2004 From: olischulz at web.de (Oliver Schulz) Date: Mon, 9 Feb 2004 21:31:59 +0100 Subject: AW: [En-Nut-Discussion] NutUdpSendTo problem In-Reply-To: <5.1.1.6.0.20040209201809.03238ae8@egnite.de> Message-ID: <000e01c3ef4b$c50cc540$5b42a8c0@ose.de> Hi Rich & Harald, some additional annotations to Haralds posting: > I have to admit too, that I never tried routing with > with Ethernut's UDP, but, as routing is implemented > in the IP layer and used by TCP too, I'm quite sure > that this should work. While testing the sntp stuff, I extensively used routing for UDP packets and it worked fine. I always took directly ntp1.ptb.de as time server. > > In your output > EEPROM/DHCP/ARP config failed > never appears, so you are using DHCP. May be there's the > problem. Can you please try to use Well, but DHCP is even *not* used if in confnet struct a valid ip address and subnet mask is stored. NutDhcpIfConfig only starts the dhcp thread if no ip address (0.0.0.0) is stored in EEPROM. Otherwise the EEPROM configuration is used to configure the interface (which is not bad at all), but the stored gateway ip address is unfortunately ignored and then no default route is available. I already commited a bugfix to nut-3_4-release, which was initially intended to be applied in HEAD branch only. ...Uuhhh merging from HEAD branch, hope Harald will not kill me for this... Regards, Oliver. From ethernut at objenv.com Mon Feb 9 21:39:02 2004 From: ethernut at objenv.com (Rich Wellner) Date: Mon, 09 Feb 2004 14:39:02 -0600 Subject: [En-Nut-Discussion] NutUdpSendTo problem In-Reply-To: <5.1.1.6.0.20040209201809.03238ae8@egnite.de> (Harald Kipp's message of "Mon, 09 Feb 2004 20:40:20 +0100") References: <000001c3b9b3$cf7ce820$1601a8c0@p3> <000001c3b9b3$cf7ce820$1601a8c0@p3> <5.1.1.6.0.20040209201809.03238ae8@egnite.de> Message-ID: <87vfmg56op.fsf@objenv.com> Harald Kipp writes: > In your output > EEPROM/DHCP/ARP config failed > never appears, so you are using DHCP. May be there's the > problem. Can you please try to use > > NutNetIfConfig("eth0", mac, ip_addr, ip_mask); > NutIpRouteAdd(0, 0, inet_addr("207.252.251.233"), &devEth0); > > instead of NutDhcpIfConfig()? Well, this is something to try anyway. And I confess I hadn't noticed that the "config failed" line wasn't in the output. *I* know that there is no DHCP server so somehow developed a blind spot for this. I'll try the above and see what happens. If nothing else perhaps poking it with a different stick will produce a different error. Thanks for having a look and making a suggestion. rw2 From harald.kipp at egnite.de Mon Feb 9 21:34:16 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 09 Feb 2004 21:34:16 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <402381BE.4070605@telogis.com> References: <5.1.1.6.0.20040205105833.031cf3e0@egnite.de> <5.1.1.6.0.20040205105833.031cf3e0@egnite.de> Message-ID: <5.1.1.6.0.20040209210115.032d1f68@egnite.de> Hi Ralph, At 00:59 07.02.2004 +1300, you wrote: >Harald Kipp wrote >> >>I'm afraid, that it's not that simple. As far as I >>understood, the low cost thumbs are running with >>32 bit access in internal memory only. Having Nut/OS >>and the application in on-chip RAM is an advantage. > >But running thumb from 16 bit memory is optimal. It's all a question of >what the goal is. To me it's more performance ( to allow simpler >programing) with no more cost. But isn't 32 bit access twice as fast as 16 bit? The AT91R40008 comes with sufficient internal RAM. >>On the other hand, external flash gives more flexibility. >>It may contain the image _plus_ a file system. > >Nand flash is always cheaper for a file system (and I have a nut >compatible nand flash file system almost ready to release!) I do not know much about differences in flash memory techniques...but nand types seems to be hot. A flash file system is indeed something I'm missing. Using Michael's FAT is OK for reading, but would soon wear out the FAT table area on excessive writing. I guess, wear out is still a problem with nand flash, isn't it? >I guess at the end of the day, what is NutOS trying to be? Is it a new >ecos in the making? Does it (Do we?) support process loading? What about >AVR's - does it get so heavy as to leave them behind? Process loading is a big word...but how about a tiny little shared lib. :-) You may know that my company created Coconut, a multiport RS232, using ATmega128 as double UARTs. They are running Nut/OS (internal RAM only, of course, no TCP), which made the task of creating "intelligent" UARTs very simple. I'd also like to see Nut/OS running in an ISP dongle, LCD interface etc. >Interesting article in Linux world this month - about open source trying >to compete with itself (http://www.linuxworld.com/magazine/?issueid=352&de=1) Somehow, Open Source implicitely includes competion. If you are unsatisfied with a software project, take the source, rename it (keeping copyrights, of course) and create a new project. It's that easy. I do not follow the author's view in some points. Like he critizised "Quiet, the boss is speaking". Everybody is free to take Nut/OS, call it NewYork/OS and make it look completely different. As long as it is called Nut/OS and as long as I'm interested in it, I reserve the right to accept or deny modifications. But I try to be as tolerant as possible, but also as conservative as possible to protect our and other's investments. And it's by far not like "you're either with us or against us". My Ethernuts are happily running Contiki from time to time and the only reason for not seeing AvrX is the lack of time. Ignorance is not a fixed part of Open Source. It an adjective of some people, who cry loudest in newsgroups and mailing lists. The silent majority is very tolerant. But to get to the point, IMHO Nut/OS should keep it's kernel as simple as possible. Applications may use goodies like file systems or message queues. My view of the system is like the C programming language: Very simple, very near to the underlying hardware, but still very portable. Equipped with a powerful runtime library. Harald From ethernut at objenv.com Mon Feb 9 21:43:35 2004 From: ethernut at objenv.com (Rich Wellner) Date: Mon, 09 Feb 2004 14:43:35 -0600 Subject: AW: [En-Nut-Discussion] NutUdpSendTo problem In-Reply-To: <000e01c3ef4b$c50cc540$5b42a8c0@ose.de> ("Oliver Schulz"'s message of "Mon, 9 Feb 2004 21:31:59 +0100") References: <000e01c3ef4b$c50cc540$5b42a8c0@ose.de> Message-ID: <87r7x456h4.fsf@objenv.com> "Oliver Schulz" writes: > Hi Rich & Harald, > > some additional annotations to Haralds posting: > >> I have to admit too, that I never tried routing with with Ethernut's UDP, >> but, as routing is implemented in the IP layer and used by TCP too, I'm >> quite sure that this should work. > While testing the sntp stuff, I extensively used routing for UDP packets and > it worked fine. I always took directly ntp1.ptb.de as time server. Is this code available in any form? I'd be happy at this point to have *any* code working and then work my way back up from there. >> In your output EEPROM/DHCP/ARP config failed never appears, so you are >> using DHCP. May be there's the problem. Can you please try to use > Well, but DHCP is even *not* used if in confnet struct a valid ip address > and subnet mask is stored. NutDhcpIfConfig only starts the dhcp thread if no > ip address (0.0.0.0) is stored in EEPROM. Otherwise the EEPROM > configuration is used to configure the interface (which is not bad at all), > but the stored gateway ip address is unfortunately ignored and then no > default route is available. Ah. Yes, this makes sense. But perhaps Harald's test does me no good then. Well, I'll try it anyway. Again, poke with a different stick, who knows. I'm also going to try converting this to a TCP stack and see what happens. I suppose there is a remote possibility that I have a physical layer problem. rw2 From olischulz at web.de Mon Feb 9 22:12:46 2004 From: olischulz at web.de (Oliver Schulz) Date: Mon, 9 Feb 2004 22:12:46 +0100 Subject: AW: AW: [En-Nut-Discussion] NutUdpSendTo problem In-Reply-To: <87r7x456h4.fsf@objenv.com> Message-ID: <000f01c3ef51$77a88c70$5b42a8c0@ose.de> Hi Rich, > > While testing the sntp stuff, I extensively used routing > for UDP packets and > > it worked fine. I always took directly ntp1.ptb.de as time server. > > Is this code available in any form? I'd be happy at this > point to have *any* > code working and then work my way back up from there. Of couse. The sntp protocol is already included in Nut/OS. Look in pro/sntp.c and include/pro/sntp.h for some details. Unfortunately I missed to write some dox about sntp jet (sorry). In http://www.ethernut.de/arc/ostime-104.zip you'll find a readme file with some explanations. So long, Oliver. From zodianet at wanadoo.fr Mon Feb 9 22:32:15 2004 From: zodianet at wanadoo.fr (Zodianet) Date: Mon, 9 Feb 2004 22:32:15 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms (Porsche 911 is better than a Golf but sorry , I need a small car) In-Reply-To: <5.1.1.6.0.20040209204553.03227d50@egnite.de> Message-ID: <20040209213418.5988A1BFD3E8@mwinf0102.wanadoo.fr> Harald, I have just no time to debug Nut/OS and even if it is small, it's complex. It's very easy to spend a lot of time for this task. I need a reliable OS like other users I think. For my job, I worked on a BSD stack adaptation because the native stack of a well-known real-time OS was bugged(... and very expensive). Big CPU, memories, big problems ... But for my friends, small != TCP/IP. Definitively. Instead BSD & Linux, nothing.... Of course, a Porsche 911 is better than a Golf but I need a small car. Smallest as possible. With Nut/OS, I do the same things with I=100mA and 32K of RAM with a near cold board. I am nicely surprised. So small! Perfect for my needs. And it works.(the last TCP updates are very good). Really, no hidden critics :-) But reliability very is important ;-) Nut/OS has no MMU. Yes, but MMU is only useful when tasks are bugged. Waste a little time to create an abstraction layer and then develop , test, debug your high layer applications on confortable environment e.g. PC, linux, Windows (equiped with MMU) and without real-time constraints (very important). Create I/O simulators if needed. And when all is OK,compile and test your software on the target. (in fact, the both compilers windows are always open here and point to the same sources) And... maintain dual environment for portability and bug tracking. In fact, you will save a lot of time. No MMU is no problem. Except for 10 exp(6) lines of code, system, low layers or I/O oriented applications. Jean Pierre -----Message d'origine----- De : en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de] De la part de Harald Kipp Envoy? : lundi 9 f?vrier 2004 20:58 ? : Ethernut User Chat (English) Objet : RE: [En-Nut-Discussion] Supporting Other Target Platforms Hi Jean Pierre, At 12:42 05.02.2004 +0100, you wrote: >I am not sure that Nut/OS needs a great "CPU upsizing" today but it >needs to become first more reliable before migrate! Do I detect hidden critics here? :-) Nut/OS will never be as reliable as larger systems, which offer MMU and protected memory regions. The cooperative threading adds additional traps. That's why it's more difficult to write reliable applications for Nut/OS compared to Linux. >Other bigger OS are in place and could be a better choice for bigger >CPUs to fill quickly 512K of Flash ;-). > For example, if you want to create an MP3 Ethernet player, you can use hardware. If you want to add Ogg Vorbis, you are lost (no idea, wether there are any hardware de/encoders available in the meantime, just to give an example). So you need raw power, but no eCos, Linux or whatever. Just something simple with a little bit TCP would do. That's at least my motivation. I'd like to see my GameBoy playing MPEG movies, which I transfered on it's CompactFlash card via FTP. Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From thomas at juletraesfoden.dk Mon Feb 9 22:36:36 2004 From: thomas at juletraesfoden.dk (=?iso-8859-1?Q?Thomas_M=F8rch?=) Date: Mon, 9 Feb 2004 22:36:36 +0100 Subject: [En-Nut-Discussion] eaglecad template Message-ID: <001801c3ef54$cbabef80$6402a8c0@laptop> Hey, why didn't I see that there finaly was a template for expansion boards.. Thanks Harald... Now I can concentrate on making my LCD interface, and make a driver for it.. (Unless someone already has made a driver for the SED1335 LCD controler?) Regards Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040209/22ab7da3/attachment.html From ethernut at objenv.com Mon Feb 9 22:52:30 2004 From: ethernut at objenv.com (Rich Wellner) Date: Mon, 09 Feb 2004 15:52:30 -0600 Subject: AW: AW: [En-Nut-Discussion] NutUdpSendTo problem In-Reply-To: <000f01c3ef51$77a88c70$5b42a8c0@ose.de> ("Oliver Schulz"'s message of "Mon, 9 Feb 2004 22:12:46 +0100") References: <000f01c3ef51$77a88c70$5b42a8c0@ose.de> Message-ID: <87n07r6hup.fsf@objenv.com> "Oliver Schulz" writes: >> Is this code available in any form? I'd be happy at this point to have >> *any* code working and then work my way back up from there. > Of couse. The sntp protocol is already included in Nut/OS. Look in > pro/sntp.c and include/pro/sntp.h for some details. I just downloaded 3.3.2 and don't see it... > Unfortunately I missed to write some dox about sntp jet (sorry). In > http://www.ethernut.de/arc/ostime-104.zip you'll find a readme file with > some explanations. I see the files are in this zip, did you mean for me to unpack this into an existing tree? rw2 From zodianet at wanadoo.fr Mon Feb 9 22:56:55 2004 From: zodianet at wanadoo.fr (Zodianet) Date: Mon, 9 Feb 2004 22:56:55 +0100 Subject: [En-Nut-Discussion] eaglecad template In-Reply-To: <001801c3ef54$cbabef80$6402a8c0@laptop> Message-ID: <20040209215858.00A571BFFFBA@mwinf0102.wanadoo.fr> Do you know that? http://www.ramtex.dk/products/lcdd1335.htm _____ De : en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de] De la part de Thomas M?rch Envoy? : lundi 9 f?vrier 2004 22:37 ? : Ethernut User Chat (English) Objet : [En-Nut-Discussion] eaglecad template Hey, why didn't I see that there finaly was a template for expansion boards.. Thanks Harald... Now I can concentrate on making my LCD interface, and make a driver for it.. (Unless someone already has made a driver for the SED1335 LCD controler?) Regards Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040209/904e8ac1/attachment.htm From thomas at juletraesfoden.dk Mon Feb 9 23:02:35 2004 From: thomas at juletraesfoden.dk (=?iso-8859-1?Q?Thomas_M=F8rch?=) Date: Mon, 9 Feb 2004 23:02:35 +0100 Subject: [En-Nut-Discussion] eaglecad template References: <20040209215858.00A571BFFFBA@mwinf0102.wanadoo.fr> Message-ID: <004301c3ef58$6d076eb0$6402a8c0@laptop> No, haven't seen that before, but anyway it's not GPL'ed code.. so won't do! Would like to contribute something to the ethernut public ;) Regards Thomas ----- Original Message ----- From: Zodianet To: 'Ethernut User Chat (English)' Sent: Monday, February 09, 2004 10:56 PM Subject: RE: [En-Nut-Discussion] eaglecad template Do you know that? http://www.ramtex.dk/products/lcdd1335.htm ------------------------------------------------------------------------------ De : en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de] De la part de Thomas M?rch Envoy? : lundi 9 f?vrier 2004 22:37 ? : Ethernut User Chat (English) Objet : [En-Nut-Discussion] eaglecad template Hey, why didn't I see that there finaly was a template for expansion boards.. Thanks Harald... Now I can concentrate on making my LCD interface, and make a driver for it.. (Unless someone already has made a driver for the SED1335 LCD controler?) Regards Thomas ------------------------------------------------------------------------------ _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040209/f1c9a992/attachment.html From olischulz at web.de Mon Feb 9 23:11:07 2004 From: olischulz at web.de (Oliver Schulz) Date: Mon, 9 Feb 2004 23:11:07 +0100 Subject: AW: AW: AW: [En-Nut-Discussion] NutUdpSendTo problem In-Reply-To: <87n07r6hup.fsf@objenv.com> Message-ID: <001f01c3ef59$9e9d69b0$5b42a8c0@ose.de> Hi Rich, sorry, it's a bit late for me and it seems, that I'm already sleeping.. :-) > I just downloaded 3.3.2 and don't see it... I forgot to say, that this sntp stuff is in CVS only, and not yet in the last official release of Nut/OS. Please use cvs to obtain the branch 'nut-3_4-release'. If your are new to cvs, I can explain the useage, but not in this mailing list. We should use then private email (mailto:olischulz at web.de). Another possibility is to use a cvs snapshot of the 3.4 release branch. You can find the latest at http://www.ethernut.de/arc/ethernut-3.4.1-rc1.tar.bz2 or look at http://www.ethernut.de/en/download.html for further infomation. But please note, that the latest bugfixes are not in the archive file, so I would prefer the cvs method. > > I see the files are in this zip, did you mean for me to > unpack this into an > existing tree? Well, I hope this is still possible. Before the stuff were added to the cvs, this zip file was intended to merge the sntp and time functions into an existing tree. But since end of november 2003, I didn't test it any longer. If you use cvs, you won't have any problems... (hopyfully :-) Cheers, Oliver. From ralph.mason at telogis.com Tue Feb 10 05:17:58 2004 From: ralph.mason at telogis.com (Ralph Mason) Date: Tue, 10 Feb 2004 17:17:58 +1300 Subject: [En-Nut-Discussion] Supporting Other Target Platforms (Porsche 911 is better than a Golf but sorry , I need a small car) In-Reply-To: <20040209213418.5988A1BFD3E8@mwinf0102.wanadoo.fr> References: <20040209213418.5988A1BFD3E8@mwinf0102.wanadoo.fr> Message-ID: <40285B76.5010802@telogis.com> Zodianet wrote: >Waste a little time to create an abstraction layer and then develop , test, >debug your high layer applications on confortable environment e.g. PC, >linux, Windows (equiped with MMU) and without real-time constraints (very >important). Create I/O simulators if needed. >And when all is OK,compile and test your software on the target. >(in fact, the both compilers windows are always open here and point to the >same sources) >And... maintain dual environment for portability and bug tracking. >In fact, you will save a lot of time. No MMU is no problem. >Except for 10 exp(6) lines of code, system, low layers or I/O oriented >applications. > > I have already done this for windows, and can run and debug the complete NutOS (except Ethernet drivers) using visual stido. Ralph From tyou at i-da.co.jp Tue Feb 10 06:10:03 2004 From: tyou at i-da.co.jp (TYOU) Date: Tue, 10 Feb 2004 14:10:03 +0900 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <5.1.1.6.0.20040209210115.032d1f68@egnite.de> References: <5.1.1.6.0.20040205105833.031cf3e0@egnite.de> <5.1.1.6.0.20040205105833.031cf3e0@egnite.de> <5.1.1.6.0.20040209210115.032d1f68@egnite.de> Message-ID: <402867AB.1010505@i-da.co.jp> hi , Guys I think RISC186 series MCU from www.rdc.com.tw is a choice for Nut/OS. Low cost, high performance, easy available C compilier (BC), and even with 2 10/100M MAC controllers on chip(*R2020C *); SDRAM controller and UART with FIFO. http://www.rdc.com.tw/ProductInfo.asp As for NAND FLASH, it is more appropriate for file system because it has smaller sector size than NOR type FLASH. Coming with ATMEL ethernet develop kit, there is a simple linear flash file system, but it has not been opimized for writing. YAFFS is a portable ffs with embedded support, but it has strict license. Ralph! Waiting for your release! :-) Tyou From zodianet at wanadoo.fr Tue Feb 10 08:28:34 2004 From: zodianet at wanadoo.fr (Zodianet) Date: Tue, 10 Feb 2004 08:28:34 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms (Porsche911 is better than a Golf but sorry , I need a small car) In-Reply-To: <40285B76.5010802@telogis.com> Message-ID: <20040210073037.6422D18000FE@mwinf0903.wanadoo.fr> Lucky boy! fdopen doesn't work here with winsock, is this problem resolved for you ? So, I/O streams are emulated by not very attractive send/recv (a packet of fputc() may crash XP). JP >Waste a little time to create an abstraction layer and then develop , >test, debug your high layer applications on confortable environment >e.g. PC, linux, Windows (equiped with MMU) and without real-time >constraints (very important). Create I/O simulators if needed. >And when all is OK,compile and test your software on the target. >(in fact, the both compilers windows are always open here and point to >the same sources) And... maintain dual environment for portability and >bug tracking. >In fact, you will save a lot of time. No MMU is no problem. >Except for 10 exp(6) lines of code, system, low layers or I/O oriented >applications. > > I have already done this for windows, and can run and debug the complete NutOS (except Ethernet drivers) using visual stido. Ralph _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From ralph.mason at telogis.com Tue Feb 10 08:35:39 2004 From: ralph.mason at telogis.com (Ralph Mason) Date: Tue, 10 Feb 2004 20:35:39 +1300 Subject: [En-Nut-Discussion] Supporting Other Target Platforms (Porsche911 is better than a Golf but sorry , I need a small car) In-Reply-To: <20040210073037.6422D18000FE@mwinf0903.wanadoo.fr> References: <20040210073037.6422D18000FE@mwinf0903.wanadoo.fr> Message-ID: <402889CB.7050009@telogis.com> I have written windows comport drivers for windows. Then use an external modem, with ppp. Ralph > >Lucky boy! >fdopen doesn't work here with winsock, is this problem resolved for you ? >So, I/O streams are emulated by not very attractive send/recv (a packet of >fputc() may crash XP). >JP > > > > >>Waste a little time to create an abstraction layer and then develop , >>test, debug your high layer applications on confortable environment >>e.g. PC, linux, Windows (equiped with MMU) and without real-time >>constraints (very important). Create I/O simulators if needed. >>And when all is OK,compile and test your software on the target. >>(in fact, the both compilers windows are always open here and point to >>the same sources) And... maintain dual environment for portability and >>bug tracking. >>In fact, you will save a lot of time. No MMU is no problem. >>Except for 10 exp(6) lines of code, system, low layers or I/O oriented >>applications. >> >> >> >> > >I have already done this for windows, and can run and debug the complete >NutOS (except Ethernet drivers) using visual stido. > >Ralph > >_______________________________________________ >En-Nut-Discussion mailing list >En-Nut-Discussion at egnite.de >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > >_______________________________________________ >En-Nut-Discussion mailing list >En-Nut-Discussion at egnite.de >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > From zodianet at wanadoo.fr Tue Feb 10 08:44:49 2004 From: zodianet at wanadoo.fr (Zodianet) Date: Tue, 10 Feb 2004 08:44:49 +0100 Subject: [En-Nut-Discussion] Realtek 8019AS second sourced? In-Reply-To: <20040210073037.6422D18000FE@mwinf0903.wanadoo.fr> Message-ID: <20040210074651.ED23B1800144@mwinf0904.wanadoo.fr> The Eth chip of my Ethernut 1.3 is a RMC RTL8019AS. It's a Realtek compatible? or Realtek chip? Is 8019AS second sourced? Jean Pierre From togrady at comtech.uk.com Tue Feb 10 10:24:58 2004 From: togrady at comtech.uk.com (Trevor O'Grady) Date: Tue, 10 Feb 2004 09:24:58 -0000 Subject: [En-Nut-Discussion] Supporting Other Target Platforms (Porsche911 is better than a Golf but sorry , I need a small car) In-Reply-To: <40285B76.5010802@telogis.com> Message-ID: Ralph, This is very interesting. I was considering doing something like this. I have done this several times in the past for other systems and it is well worth the effort. You find bugs that otherwise would not be found in normal testing on the hardware. You can usually write 90% of your application in this nice environment. Is this something you would be willing to share ? Regards Trevor -----Original Message----- From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de]On Behalf Of Ralph Mason Sent: 10 February 2004 04:18 To: Ethernut User Chat (English) Subject: Re: [En-Nut-Discussion] Supporting Other Target Platforms (Porsche911 is better than a Golf but sorry , I need a small car) Zodianet wrote: >Waste a little time to create an abstraction layer and then develop , test, >debug your high layer applications on confortable environment e.g. PC, >linux, Windows (equiped with MMU) and without real-time constraints (very >important). Create I/O simulators if needed. >And when all is OK,compile and test your software on the target. >(in fact, the both compilers windows are always open here and point to the >same sources) >And... maintain dual environment for portability and bug tracking. >In fact, you will save a lot of time. No MMU is no problem. >Except for 10 exp(6) lines of code, system, low layers or I/O oriented >applications. > > I have already done this for windows, and can run and debug the complete NutOS (except Ethernet drivers) using visual stido. Ralph _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From harald.kipp at egnite.de Tue Feb 10 10:36:47 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 10 Feb 2004 10:36:47 +0100 Subject: [En-Nut-Discussion] Realtek 8019AS second sourced? In-Reply-To: <20040210074651.ED23B1800144@mwinf0904.wanadoo.fr> References: <20040210073037.6422D18000FE@mwinf0903.wanadoo.fr> Message-ID: <5.1.1.6.0.20040210103444.01bbb200@egnite.de> I found a few links on Google only, no real info. Mh...quite interesting. Does anybody know more about this? Harald At 08:44 10.02.2004 +0100, you wrote: > >The Eth chip of my Ethernut 1.3 is a RMC RTL8019AS. >It's a Realtek compatible? or Realtek chip? >Is 8019AS second sourced? >Jean Pierre From j.v.d.stoel at stream-it.nl Tue Feb 10 12:08:19 2004 From: j.v.d.stoel at stream-it.nl (Johan van der Stoel (Streamit)) Date: Tue, 10 Feb 2004 12:08:19 +0100 Subject: [En-Nut-Discussion] RE: RMC RTL8019AS In-Reply-To: <20040210110004.1C7412F42A1@p15095813.pureserver.info> Message-ID: <001301c3efc6$30fa50e0$2802a8c0@p42400> Dear Jean Pierre, This is just the Realtek chip. Just have a look at the datasheet and you will see the same logo. Johan Date: Tue, 10 Feb 2004 08:44:49 +0100 From: "Zodianet" Subject: RE: [En-Nut-Discussion] Realtek 8019AS second sourced? To: "'Ethernut User Chat (English)'" Message-ID: <20040210074651.ED23B1800144 at mwinf0904.wanadoo.fr> Content-Type: text/plain; charset="us-ascii" The Eth chip of my Ethernut 1.3 is a RMC RTL8019AS. It's a Realtek compatible? or Realtek chip? Is 8019AS second sourced? Jean Pierre From ethernut at objenv.com Tue Feb 10 20:32:41 2004 From: ethernut at objenv.com (Rich Wellner) Date: Tue, 10 Feb 2004 13:32:41 -0600 Subject: [En-Nut-Discussion] NutUdpSendTo problem -- follow up (still not working) Message-ID: <871xp2ohly.fsf@objenv.com> Thanks for the tips from yesterday. I've made some changes and still cannot send to the Internet, but can now see packets on my local network. The only thing I have to go on right now is that the gateway may not be getting set properly. Output is below. I don't understand why NutIpRouteAdd returns success but an immediate call to NutIpRouteQuery returns a null NUTDEVICE and ip address of 0. Output: UDP Monitor Daemon, Nut/OS: 3.4.1.1 route: 0 device: 0 Queried: 0.0.0.0 ip: 207.252.251.238 netmask: 255.255.255.248 gateway: 207.252.251.233 dest ip: 216.127.80.16 return: -1 Source: int main(void) { u_long baud = 115200; u_char i; u_long dest_addr; UDPSOCKET *udpsock; /* * Initialize the uart device. */ NutRegisterDevice(&devDebug0, 0, 0); freopen("uart0", "w", stdout); _ioctl(_fileno(stdout), UART_SETSPEED, &baud); NutSleep(200); printf("\n\nUDP Monitor Daemon, Nut/OS: %s\n", NutVersionString()); #ifdef NUTDEBUG NutTraceTcp(stdout, 0); NutTraceOs(stdout, 0); NutTraceHeap(stdout, 0); NutTracePPP(stdout, 0); #endif /* * Register Ethernet controller. */ //if(NutRegisterDevice(&devSmsc111, 0, 0)) if (NutRegisterDevice(&devEth0, 0x8300, 5)) puts("Registering device failed"); u_char mac[] = { MYMAC }; u_long ip_addr = inet_addr(MYIP); u_long ip_mask = inet_addr(MYMASK); NutNetIfConfig("eth0", mac, ip_addr, ip_mask); printf("route: %d\n", NutIpRouteAdd(0, 0, inet_addr("207.252.251.233"), &devEth0)); printf("device: %d\n", NutIpRouteQuery(inet_addr("216.127.80.16"), &ip_addr)); printf("Queried: %s\n", inet_ntoa(ip_addr)); printf("ip: %s\n", inet_ntoa(confnet.cdn_ip_addr)); printf("netmask: %s\n", inet_ntoa(confnet.cdn_ip_mask)); printf("gateway: %s\n", inet_ntoa(confnet.cdn_gateway)); udpsock = NutUdpCreateSocket(0); dest_addr = inet_addr("216.127.80.16"); printf("dest ip: %s\n", inet_ntoa(dest_addr)); /* * We could do something useful here, like serving a watchdog. */ NutThreadSetPriority(254); for (;;) { printf("return: %d\n", NutUdpSendTo(udpsock, dest_addr, 2526, "test", 4)); NutSleep(1000); } } From ethernut at objenv.com Tue Feb 10 23:58:13 2004 From: ethernut at objenv.com (Rich Wellner) Date: Tue, 10 Feb 2004 16:58:13 -0600 Subject: [En-Nut-Discussion] NutUdpSendTo problem -- It's alive! In-Reply-To: <871xp2ohly.fsf@objenv.com> (Rich Wellner's message of "Tue, 10 Feb 2004 13:32:41 -0600") References: <871xp2ohly.fsf@objenv.com> Message-ID: <87n07qmtiy.fsf@objenv.com> Rich Wellner writes: > Thanks for the tips from yesterday. I've made some changes and still cannot > send to the Internet, but can now see packets on my local network. Aha! Oliver sent a private mail with another idea and it turned me in the right direction. His idea was to include a routine to dump more state about the ip stack, but I couldn't get it to compile. I was missing net/route.h from the include list. That file is also where the methods I need to setup my routing live and its absence was the core problem. Once I include that everything works fine. So, thanks to Harald and Oliver for the help, I'm not ready to send packets all over the world and pay closer attention to compiler warnings. rw2 From dferbas at dfsoft.cz Wed Feb 11 01:33:38 2004 From: dferbas at dfsoft.cz (Dusan Ferbas) Date: Wed, 11 Feb 2004 01:33:38 +0100 Subject: [En-Nut-Discussion] GPRS PAP problem Message-ID: <6.0.1.1.2.20040211013022.01d27938@pop3.vol.cz> Hi, I don't have answers for all your question. Just one column. Once the targeting servers confirms no PCOMP and ACOMP during LCP it should stay with it. I experienced only a behaviour that a server was not able to negotiate other than both compress modes off. There were up to 10 attempts with 3 secs intervals and then PPP session was closed by my PPP client. >My real problem is that PAP authentication messages seem to be ignored by my >GPRS server. The server requires a blank username and password. I have >tried blank. I have tried passwords. I have even tried rejecting the >(AUTH=0xC023) request from the server. Still I'm being ignored (except for >the latter where I get a TERMREQ when it is time for IPCP negotiation). >Has anyone experienced this? Could it be that the server is speechless >without PCOMP and ACOMP? Dusan From francois at asnone.com Wed Feb 11 09:14:37 2004 From: francois at asnone.com (Francois Rademeyer) Date: Wed, 11 Feb 2004 10:14:37 +0200 Subject: [En-Nut-Discussion] GPRS PAP problem References: <6.0.1.1.2.20040211013022.01d27938@pop3.vol.cz> Message-ID: <000501c3f077$1a1c42a0$1b00a8c0@sonyfrademeyer> Hi, I resolved the problem by implementing PCOMP and ACOMP in the PPP layer. Seems like my ISP has a sub-standard stack. So much for RFCs. There seems to be so many versions of the NutOS PPP files flying around and I would like to check my changes in. Who is the moderator? Cheers, Francois ----- Original Message ----- From: "Dusan Ferbas" To: Sent: Wednesday, February 11, 2004 2:33 AM Subject: [En-Nut-Discussion] GPRS PAP problem > Hi, > > I don't have answers for all your question. Just one column. Once the > targeting servers confirms no PCOMP and ACOMP during LCP it should stay > with it. > > I experienced only a behaviour that a server was not able to negotiate > other than both compress modes off. There were up to 10 attempts with 3 > secs intervals and then PPP session was closed by my PPP client. > > >My real problem is that PAP authentication messages seem to be ignored by my > >GPRS server. The server requires a blank username and password. I have > >tried blank. I have tried passwords. I have even tried rejecting the > >(AUTH=0xC023) request from the server. Still I'm being ignored (except for > >the latter where I get a TERMREQ when it is time for IPCP negotiation). > >Has anyone experienced this? Could it be that the server is speechless > >without PCOMP and ACOMP? > > Dusan > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From harald.kipp at egnite.de Wed Feb 11 09:21:07 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 11 Feb 2004 09:21:07 +0100 Subject: [En-Nut-Discussion] GPRS PAP problem In-Reply-To: <000501c3f077$1a1c42a0$1b00a8c0@sonyfrademeyer> References: <6.0.1.1.2.20040211013022.01d27938@pop3.vol.cz> Message-ID: <5.1.1.6.0.20040211092009.02ccfeb0@egnite.de> Francois, Please send all PPP related changes to me harald at egnite dot de. Thanks From harald.kipp at egnite.de Wed Feb 11 09:43:11 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 11 Feb 2004 09:43:11 +0100 Subject: [En-Nut-Discussion] NutUdpSendTo problem -- It's alive! In-Reply-To: <87n07qmtiy.fsf@objenv.com> References: <871xp2ohly.fsf@objenv.com> <871xp2ohly.fsf@objenv.com> Message-ID: <5.1.1.6.0.20040211093229.02ae6cb8@egnite.de> Rich, good you solved the problem. I'm very sensitive to compiler warnings. The complete source should compile without any warning. 'make > mk.log' should not produce any output. Ted added a compiler option for treating warnings as errors, but I removed this. I thoght, it's a bit too drastic. Regards, Harald P.S.: Oliver, can you please add a final linefeed to the last line of irqstack.h. At least with GCC 3.5 this produces a warning. From enut at ixo.de Wed Feb 11 13:20:42 2004 From: enut at ixo.de (Waschk,Kolja) Date: Wed, 11 Feb 2004 13:20:42 +0100 (CET) Subject: [En-Nut-Discussion] Problem with CPU clock freq computation Message-ID: Hi On a selfmade board similar to the Ethernut 1, I experience a weird effect involving NutComputeCpuClock(). The computed cpu_clock is 12287200 Hz, which is almost exactly 5/6 of 14,745600 MHz. Actually we use a 14,7456 MHz crystal. The clock crystal has the usual 32,768 kHz. Measurements proved that the actual clocks ARE 14,745600 MHz resp. 32,768 kHz. Then, e.g. UART baud rate is only correctly set up if CPU clock freq of 14,7456 MHz was hardcoded (e.g. using -DNUT_CPU_FREQ=14745600). Did anyone had some similar effect in the past and has an explanation for me? Fuses of the m128 are set to 0xFF 0x03 0x3F, i.e. longest startup time. Pausing the m128 just before NutComputeCpuClock (via JTAG) doesn't have any effect on the outcome of the computation. It always yields 12287200. I'm using gcc 3.3.2, BTW. The most "visible" difference to the Ethernut 1.3F is that we're using a 32,768 kHz crystal in SMD package. But as I said above, the actual clock looks correct when measured with external equipment. Thanks for hints in advance Kolja -- mr. kolja waschk - haubach-39 - 22765 hh - ger phone +49 40 889130-34 - fax -35 - e-mail s.a. From bbuenaobra at nip.upd.edu.ph Thu Feb 12 05:25:58 2004 From: bbuenaobra at nip.upd.edu.ph (Berns J. Buenaobra) Date: Wed, 11 Feb 2004 20:25:58 -0800 Subject: [En-Nut-Discussion] Re: [En-Nut-Announce] Webport Application Update References: <5.1.1.6.0.20040210182907.0330e920@egnite.de> Message-ID: <001e01c3f120$510b5310$6565a8c0@instru.nip.upd.edu.ph> This is indeed wonderful news! Exciting to me and my co-workers at the lab! 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-920-5474 Mobile: 0916-255-0056 URL: www.nip.upd.edu.ph/ipl *************************************** ----- Original Message ----- From: "Harald Kipp" To: Sent: Tuesday, February 10, 2004 9:32 AM Subject: [En-Nut-Announce] Webport Application Update > The Webport application sample > http://www.ethernut.de/app/webport/index.html > > has been ported to Nut/OS 3.x > http://www.ethernut.de/arc/webp201.zip > > Enjoy, > Harald Kipp > > > _______________________________________________ > En-Nut-Announce mailing list > En-Nut-Announce at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-announce > From 021243 at student.hit.no Wed Feb 11 13:50:36 2004 From: 021243 at student.hit.no (Sigurd Kleppan) Date: Wed, 11 Feb 2004 13:50:36 +0100 Subject: [En-Nut-Discussion] DS1620 temp sensor Message-ID: In my project with Ethernut i want to log som temperatures. I use DS1620 and to get the temp. I have to send 0xAA to the device. Then i get the temp back. I have written a code to send the data, but it is not working. Can you see some error and give me some hints on whats wrong in the Get1620byte and Put1620byte functions please. Do you know someone who have written code for DS1620 i Ethernut? Thank you! Sigurd //THE TEMPERATURE CODE unsigned char Get1620byte( void ) { unsigned char j,k=0,b=1; outp(0x00,DDRB); outp(0x00,PORTB); for (j=0; j<8; j++) { cbi(PORTB,0); //CLK=0; if (bit_is_set(PINB, 3)){ k|=b;} sbi(PORTB,0); //CLK=1; b=(b<<1); /* Setup for next read and or */ } cbi(PORTB,0); cbi(PORTB,3); return k; } unsigned char Put1620byte(unsigned char m) { unsigned char k,b=1; unsigned char DQ; outp(0xFF,DDRB); cbi(PORTB,0); cbi(PORTB,3); sbi(PORTB,5); //RST=1; for (k=0; k<8; k++) { cbi(PORTB,0); //CLK=0; DQ[k] = (m & b); if(!DQ==0){ sbi(PORTB,3);} else{cbi(PORTB,3);} sbi(PORTB,0); //CLK=1; b=(b<<1); /* Setup to send next bit */ } cbi(PORTB,0); cbi(PORTB,3); return 0; } void main(){ sbi(PORTB,5); // RST=1; Put1620byte(0xAA)); temp_and_half_bit = Get1620byte(); /* read 1st byte of temp */ sign_bit = Get1620byte(); /* read 2nd byte of temp */ cbi(PORTB,5); fprintf(stream,"%d",temp_and_half_bit); } From conorduke at yahoo.co.uk Wed Feb 11 14:51:28 2004 From: conorduke at yahoo.co.uk (=?iso-8859-1?q?Conor=20Duke?=) Date: Wed, 11 Feb 2004 13:51:28 +0000 (GMT) Subject: [En-Nut-Discussion] RE:NIC reset Failed Message-ID: <20040211135128.78992.qmail@web25002.mail.ukl.yahoo.com> Hey, Newbie problem ,please bear with me as i'm sure the solution is quite simple. Everything was working fine i have set up a http server that was monitoring a plc controller but when i began to try and setup LED's on the expansion port .The ethernet connection stopped working. so i loaded the HTTPserver demo and i got no response then i loaded BASEMON and recieved the following ; NIC hardware reset...failed Trying NIC software reset...failed NIC id detection... failed, got 0x0A0B, expected 0x5070 NIC hardware reset...failed Trying NIC software reset...failed NIC id detection... failed, got 0x0A0B, expected 0x5070 I/O Port Test... PORTE bits FC I read a similar post to with the exact same problem but no1 replied so i am assuming ther is an easy way to solve it ,but my thesis is due in 2 weeks so i need the EASY way out unfortunatly. Do i need a new chip or can i fix it on my own, Any help would be greatly appriciated Yours in Eternal Gratitude Regards Conor --------------------------------- BT Yahoo! Broadband - Free modem offer, sign up online today and save ?80 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040211/f49f5b97/attachment.htm From harald.kipp at egnite.de Wed Feb 11 19:41:58 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 11 Feb 2004 19:41:58 +0100 Subject: [En-Nut-Discussion] Problem with CPU clock freq computation In-Reply-To: Message-ID: <5.1.1.6.0.20040211193556.031e86e8@egnite.de> Kolja, >Fuses of the m128 are set to 0xFF 0x03 0x3F, i.e. longest startup time. Nothing around here right now to check the fuses, but I guess this differs. Did you set CKOPT? We never experienced this problem. If you measured correct frequencies, there must be another difference, I'm sure. Harald From harald.kipp at egnite.de Wed Feb 11 20:02:54 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 11 Feb 2004 20:02:54 +0100 Subject: [En-Nut-Discussion] RE:NIC reset Failed In-Reply-To: <20040211135128.78992.qmail@web25002.mail.ukl.yahoo.com> Message-ID: <5.1.1.6.0.20040211194819.032a7758@egnite.de> Hi Conor, the only post I can find was from Gert Jan Kruizinga, about one year ago. He was part of the robot contest team and I later heard from Peter Kunst, that they had indeed two boards broken. Specially the RTL8019AS is very sensitive to ESD and in the first place of chips getting effected. Second is the ATmega, as you can imagine. You didn't change anything else? Power supply? Add on board? Try to put everything in it's initial status and use Basemon to check the board. Please also post the full basemon report including version banner to info at egnite dot de. >I read a similar post to with the exact same problem but no1 replied so i >am assuming ther is an easy way to solve it ,but my thesis is due in 2 >weeks so i need the EASY way out unfortunatly. This sounds familiar and made my name entered here :-) http://innovexpo.itee.uq.edu.au/2003/exhibits/s354335/thesis.pdf Toby had been in the same situation, but he was in Queensland, 2 shipping weeks away...and we get it done. So don't worry. >Do i need a new chip or can i fix it on my own, Not recommended. We replace ATmegas, Realteks and SMSC from time to time...just for fun and training. It usually fails, if you do not own very expensive hot air equipment. The 2000 US$ irons are _not_ the expensive ones. I'll contact you by private email. Harald From dferbas at dfsoft.cz Thu Feb 12 12:26:56 2004 From: dferbas at dfsoft.cz (Dusan Ferbas) Date: Thu, 12 Feb 2004 12:26:56 +0100 Subject: [En-Nut-Discussion] DS1620 temp sensor Message-ID: <6.0.1.1.2.20040212121919.01cc61f0@pop3.vol.cz> Hi, insert required delays into main(). Follow AC characteristics and waveforms from Maxim's datasheet. E.g. in Put1620byte() you have DQ[k] ! There are application notes at Maxim's site. >In my project with Ethernut i want to log som temperatures. I use DS1620 >and to get the temp. I have to send 0xAA to the device. Then i get the >temp back. >I have written a code to send the data, but it is not working. Can you see >some error and give me some hints on whats wrong in the Get1620byte and >Put1620byte functions please. Dusan From rsloan2003 at hotmail.com Thu Feb 12 20:07:40 2004 From: rsloan2003 at hotmail.com (Richard Sloan) Date: Thu, 12 Feb 2004 14:07:40 -0500 Subject: [En-Nut-Discussion] IDE interface Message-ID: Search the archives unsuccessfully for this info. What is the current stage of the IDE interface with a CPLD? I would be interested to help if I could, I have done lots of disk interfacing before. Richard. _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca From enut at ixo.de Thu Feb 12 20:30:38 2004 From: enut at ixo.de (Waschk,Kolja) Date: Thu, 12 Feb 2004 20:30:38 +0100 (CET) Subject: [En-Nut-Discussion] Problem with CPU clock freq computation In-Reply-To: <5.1.1.6.0.20040211193556.031e86e8@egnite.de> References: <5.1.1.6.0.20040211193556.031e86e8@egnite.de> Message-ID: > >Fuses of the m128 are set to 0xFF 0x03 0x3F, i.e. longest startup time. > fuses, but I guess this differs. Did you set CKOPT? Yep, and it's all right now. There have been a couple of other problems, and the output on my terminal looked perfectly as if the UART ran at a slightly wrong clock... but it turned out to be just the terminal: Garbage that comes from the m128 while flashing (via JTAG) somehow changes the charset encoding configuration for the output... > We never experienced this problem. If you > measured correct frequencies, there must be > another difference, I'm sure. There's still the confusing outcome of the NutComputeCpuClock() of 12,288 Mhz; I'll take a closer look at this issue in the coming days. Maybe I currently just misinterpret the value, or compilation without optimization resulted in a longer loop body (and thus smaller count). Our m128 definitely runs at 14,7456 MHz. If I remain quiet about this within the next days, please regard the "problem" as void :) I now have our boards completely up and running. They differ from the Ethernut1 only slightly, with 64kB RAM and the RTL8019AS "in parallel". A single I/O from m128 selects between RAM and RTL, driven by code added in nicrtl.c. However I don't think it's of general use (the upper 32kB of RAM are not used as heap but for interfacing to a host only), but if anyone is interested I'd prepare a patch for integration in CVS. Kolja -- mr. kolja waschk - haubach-39 - 22765 hh - ger phone +49 40 889130-34 - fax -35 - e-mail s.a. From enut at ixo.de Thu Feb 12 20:44:01 2004 From: enut at ixo.de (Waschk,Kolja) Date: Thu, 12 Feb 2004 20:44:01 +0100 (CET) Subject: [En-Nut-Discussion] Interrupting NutTcpSend/Receive from other thread Message-ID: Hi.. I wonder what is the "best" method to force disconnection of a TCP socket from one thread, while other threads are currently blocking on a NutTcpSend or -Receive on that socket? I could use some global flag indicating the disconnection request and "manually" post an event on the socket's so_tx_tq/so_rx_tq to wake up the other threads... Is there a better method? Kolja -- mr. kolja waschk - haubach-39 - 22765 hh - ger phone +49 40 889130-34 - fax -35 - e-mail s.a. From fischermi at t-online.de Thu Feb 12 20:58:47 2004 From: fischermi at t-online.de (Michael Fischer) Date: Thu, 12 Feb 2004 20:58:47 +0100 Subject: [En-Nut-Discussion] IDE interface Message-ID: Hello Richard, The prototype is working. But Harald has the idee to bring the CF and IDE interface togehter. Therefore I think it takes a little bit more time to produce a PCB. The problem is the CF interface, because it should support a card which is using the WAIT signal. Therefore we need a state machine in the CPLD. But we are working on it. The other problem is the voltage. The ide interface is a 5 volt interface, but the cf card should support 3.3 volt cards. Therfore we need a level shifter on the board too. I think Harald could give some more information about the estimated time to have a PCB. Harald, now its your part :-) Regards, Michael From fischermi at t-online.de Thu Feb 12 21:04:37 2004 From: fischermi at t-online.de (Michael Fischer) Date: Thu, 12 Feb 2004 21:04:37 +0100 Subject: [En-Nut-Discussion] IDE interface Message-ID: Richard, I think it could be a good idee, that you can check our interface? Are you familiar with the programming too? I have the problem if I connect 2 IDE devices like a hard disk and a cd rom, or two disk. The software supports now: - hard disk - cd rom - zip drive (100MB) - cf cards But in the moment only the read functionality. Michael From harald.kipp at egnite.de Thu Feb 12 21:04:52 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Thu, 12 Feb 2004 21:04:52 +0100 Subject: [En-Nut-Discussion] Interrupting NutTcpSend/Receive from other thread In-Reply-To: Message-ID: <5.1.1.6.0.20040212210336.0323bd50@egnite.de> NutTcpCloseSocket? From harald.kipp at egnite.de Thu Feb 12 21:15:12 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Thu, 12 Feb 2004 21:15:12 +0100 Subject: [En-Nut-Discussion] IDE interface In-Reply-To: Message-ID: <5.1.1.6.0.20040212210514.0323abb8@egnite.de> > >Harald, now its your part :-) Sigh! I know, I know.... After intensively checking interface requirements and drivers, I finally ended up with 74LVT16244/245 for both CF and IDE and a XC95144XL CPLD. Perhaps the CPLD is a bit oversized...but we do not know yet what might be required to handle the CF card's wait signal in a fancy way. Ah, yes, and I finally dropped the idea of supporting 5V CF cards. Harald From rsloan2003 at hotmail.com Thu Feb 12 21:28:51 2004 From: rsloan2003 at hotmail.com (Richard Sloan) Date: Thu, 12 Feb 2004 15:28:51 -0500 Subject: [En-Nut-Discussion] IDE interface Message-ID: Yes you do not need to support 5V only CF! Everything out there will usually work on both as there is a signal on the CF card to tell 3.3 or 5V Wait signal, I never used this before.... I will need to look this one up, I have only read CF cards and not wrote, so maybe WAIT is only for writes? Is there any schematics etc? I could look at and verify for you? Richard. >From: Harald Kipp >Reply-To: "Ethernut User Chat (English)" >To: "Ethernut User Chat (English)" >Subject: Re: [En-Nut-Discussion] IDE interface >Date: Thu, 12 Feb 2004 21:15:12 +0100 > > >> >>Harald, now its your part :-) > >Sigh! I know, I know.... > >After intensively checking interface requirements and >drivers, I finally ended up with 74LVT16244/245 for >both CF and IDE and a XC95144XL CPLD. > >Perhaps the CPLD is a bit oversized...but we do not >know yet what might be required to handle the CF card's >wait signal in a fancy way. > >Ah, yes, and I finally dropped the idea of supporting >5V CF cards. > >Harald > >_______________________________________________ >En-Nut-Discussion mailing list >En-Nut-Discussion at egnite.de >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/photos&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca From rsloan2003 at hotmail.com Thu Feb 12 21:29:54 2004 From: rsloan2003 at hotmail.com (Richard Sloan) Date: Thu, 12 Feb 2004 15:29:54 -0500 Subject: [En-Nut-Discussion] IDE interface Message-ID: Thanks! What is status on FAT16/32 writes? Richard. >From: fischermi at t-online.de (Michael Fischer) >Reply-To: "Ethernut User Chat (English)" >To: >Subject: [En-Nut-Discussion] IDE interface >Date: Thu, 12 Feb 2004 21:04:37 +0100 > >Richard, > >I think it could be a good idee, >that you can check our interface? > >Are you familiar with the programming too? >I have the problem if I connect 2 IDE devices like a hard disk and a cd >rom, >or two disk. The software supports now: > >- hard disk >- cd rom >- zip drive (100MB) >- cf cards > >But in the moment only the read functionality. > >Michael > > >_______________________________________________ >En-Nut-Discussion mailing list >En-Nut-Discussion at egnite.de >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca From rsloan2003 at hotmail.com Thu Feb 12 21:32:41 2004 From: rsloan2003 at hotmail.com (Richard Sloan) Date: Thu, 12 Feb 2004 15:32:41 -0500 Subject: [En-Nut-Discussion] IDE interface Message-ID: Have you also done any thinking of also supporting WLAN WiFI type CF cards on the same interface too? :-) Are these cards like IDE interface or memory interface... any word on this? Richard. >From: Harald Kipp >Reply-To: "Ethernut User Chat (English)" >To: "Ethernut User Chat (English)" >Subject: Re: [En-Nut-Discussion] IDE interface >Date: Thu, 12 Feb 2004 21:15:12 +0100 > > >> >>Harald, now its your part :-) > >Sigh! I know, I know.... > >After intensively checking interface requirements and >drivers, I finally ended up with 74LVT16244/245 for >both CF and IDE and a XC95144XL CPLD. > >Perhaps the CPLD is a bit oversized...but we do not >know yet what might be required to handle the CF card's >wait signal in a fancy way. > >Ah, yes, and I finally dropped the idea of supporting >5V CF cards. > >Harald > >_______________________________________________ >En-Nut-Discussion mailing list >En-Nut-Discussion at egnite.de >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From kyle at ghbraille.com Thu Feb 12 21:35:39 2004 From: kyle at ghbraille.com (Kyle Rhodes) Date: Thu, 12 Feb 2004 15:35:39 -0500 Subject: [En-Nut-Discussion] IDE interface Message-ID: <0966F93C53C483498BEE4F695383DCF0108450@fs01.ghbraille.com> Has anyone looked into the Atmel AVR IDE board that http://www.edtp.com sells? I suggest downloading the archive for the board and looking at the code. I believe it supports "AVR DOS", so I assume at least FAT16 is implemented. I also read something about CF support. Kyle Rhodes Hardware / Software Engineer gh, LLC 3000 Kent Ave Lafayette, IN 47906 (765) 775-3776 ext 205 -----Original Message----- From: Richard Sloan [mailto:rsloan2003 at hotmail.com] Sent: Thursday, February 12, 2004 3:30 PM To: en-nut-discussion at egnite.de Subject: RE: [En-Nut-Discussion] IDE interface Thanks! What is status on FAT16/32 writes? Richard. >From: fischermi at t-online.de (Michael Fischer) >Reply-To: "Ethernut User Chat (English)" >To: >Subject: [En-Nut-Discussion] IDE interface >Date: Thu, 12 Feb 2004 21:04:37 +0100 > >Richard, > >I think it could be a good idee, >that you can check our interface? > >Are you familiar with the programming too? >I have the problem if I connect 2 IDE devices like a hard disk and a cd >rom, >or two disk. The software supports now: > >- hard disk >- cd rom >- zip drive (100MB) >- cf cards > >But in the moment only the read functionality. > >Michael > > >_______________________________________________ >En-Nut-Discussion mailing list >En-Nut-Discussion at egnite.de >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin .msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From jesperh at telia.com Thu Feb 12 21:36:06 2004 From: jesperh at telia.com (Jesper Hansen) Date: Thu, 12 Feb 2004 21:36:06 +0100 Subject: [En-Nut-Discussion] IDE interface References: Message-ID: <070b01c3f1a7$da013310$6500a8c0@jeha> The WLAN cards cannot be compared to IDE interface as the register layout is completely different. Also, they only seem to work in I/O mode. /Jesper ----- Original Message ----- From: "Richard Sloan" To: Sent: Thursday, February 12, 2004 9:32 PM Subject: Re: [En-Nut-Discussion] IDE interface > Have you also done any thinking of also supporting WLAN WiFI type CF cards > on the same interface too? :-) > > Are these cards like IDE interface or memory interface... any word on this? > > Richard. > > > >From: Harald Kipp > >Reply-To: "Ethernut User Chat (English)" > >To: "Ethernut User Chat (English)" > >Subject: Re: [En-Nut-Discussion] IDE interface > >Date: Thu, 12 Feb 2004 21:15:12 +0100 > > > > > >> > >>Harald, now its your part :-) > > > >Sigh! I know, I know.... > > > >After intensively checking interface requirements and > >drivers, I finally ended up with 74LVT16244/245 for > >both CF and IDE and a XC95144XL CPLD. > > > >Perhaps the CPLD is a bit oversized...but we do not > >know yet what might be required to handle the CF card's > >wait signal in a fancy way. > > > >Ah, yes, and I finally dropped the idea of supporting > >5V CF cards. > > > >Harald > > > >_______________________________________________ > >En-Nut-Discussion mailing list > >En-Nut-Discussion at egnite.de > >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > _________________________________________________________________ > Protect your PC - get McAfee.com VirusScan Online > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From rsloan2003 at hotmail.com Thu Feb 12 21:57:26 2004 From: rsloan2003 at hotmail.com (Richard Sloan) Date: Thu, 12 Feb 2004 15:57:26 -0500 Subject: [En-Nut-Discussion] IDE interface Message-ID: Ya thats what I meant... I think.... I/O mode or Memory Mode. Cool! >From: "Jesper Hansen" >Reply-To: "Ethernut User Chat (English)" >To: "Ethernut User Chat (English)" >Subject: Re: [En-Nut-Discussion] IDE interface >Date: Thu, 12 Feb 2004 21:36:06 +0100 > >The WLAN cards cannot be compared to IDE interface as the register layout >is completely different. >Also, they only seem to work in I/O mode. > >/Jesper > >----- Original Message ----- >From: "Richard Sloan" >To: >Sent: Thursday, February 12, 2004 9:32 PM >Subject: Re: [En-Nut-Discussion] IDE interface > > > > Have you also done any thinking of also supporting WLAN WiFI type CF >cards > > on the same interface too? :-) > > > > Are these cards like IDE interface or memory interface... any word on >this? > > > > Richard. > > > > > > >From: Harald Kipp > > >Reply-To: "Ethernut User Chat (English)" > > >To: "Ethernut User Chat (English)" > > >Subject: Re: [En-Nut-Discussion] IDE interface > > >Date: Thu, 12 Feb 2004 21:15:12 +0100 > > > > > > > > >> > > >>Harald, now its your part :-) > > > > > >Sigh! I know, I know.... > > > > > >After intensively checking interface requirements and > > >drivers, I finally ended up with 74LVT16244/245 for > > >both CF and IDE and a XC95144XL CPLD. > > > > > >Perhaps the CPLD is a bit oversized...but we do not > > >know yet what might be required to handle the CF card's > > >wait signal in a fancy way. > > > > > >Ah, yes, and I finally dropped the idea of supporting > > >5V CF cards. > > > > > >Harald > > > > > >_______________________________________________ > > >En-Nut-Discussion mailing list > > >En-Nut-Discussion at egnite.de > > >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > > > _________________________________________________________________ > > Protect your PC - get McAfee.com VirusScan Online > > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > >_______________________________________________ >En-Nut-Discussion mailing list >En-Nut-Discussion at egnite.de >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From fischermi at t-online.de Thu Feb 12 22:12:00 2004 From: fischermi at t-online.de (Michael Fischer) Date: Thu, 12 Feb 2004 22:12:00 +0100 Subject: [En-Nut-Discussion] IDE interface Message-ID: Richard, WLAN: This is the problem. The WLAN card use the WAIT signal, for both, IORD and IOWR. In the moment I work with a "bus emulation". Some latch to emulate the bus access, but this takes about 1.5us .. 2us. I have measured the WAIT, on my notebook, and found waits up to 300ns. A full access CE was up to 600ns. The atmega is to fast. Without the emulation, it is possible to use the XDIV functionality of the CPU, and divide the clock to a lower access. I think this is not a good solution. Take a look in the Ethernut CF (WLAN) Interface thread. WRITE function: In the moment on hold, I am waiting on a PCB, Harald? You will find the source by Ethernut. Jesper: How is your "April Fool" working? Michael From enut at ixo.de Thu Feb 12 22:43:19 2004 From: enut at ixo.de (Waschk,Kolja) Date: Thu, 12 Feb 2004 22:43:19 +0100 (CET) Subject: [En-Nut-Discussion] Interrupting NutTcpSend/Receive from other thread In-Reply-To: <5.1.1.6.0.20040212210336.0323bd50@egnite.de> References: <5.1.1.6.0.20040212210336.0323bd50@egnite.de> Message-ID: > NutTcpCloseSocket? Almost, but that doesn't relieve me from notifying the threads blocking on NutTcpSend/Receive, does it? Ah, that may happen later automatically when NutTcpStateCloseEvent initiates NutTcpStateChange etc... Okay, I probably was (or am) blinded by the API documentation bit that says "the application must not use the socket after this call." (but *during* the call it maybe is allowed to do...) I'll try. Thanks; Kolja -- mr. kolja waschk - haubach-39 - 22765 hh - ger phone +49 40 889130-34 - fax -35 - e-mail s.a. From jesperh at telia.com Thu Feb 12 22:52:45 2004 From: jesperh at telia.com (Jesper Hansen) Date: Thu, 12 Feb 2004 22:52:45 +0100 Subject: [En-Nut-Discussion] IDE interface References: Message-ID: <072701c3f1b2$92364a10$6500a8c0@jeha> Looking at the Intersil documentation for the HFA3842 (used in D-Link DCF-660 and Netgear MA701), they state a max WAIT of 12.000 nS !! In my port I/O based version, I've been using 6 nops (at 7.37 MHz), which seems to be enough. A bit difficult to say for sure though, but I've transferred a number of files forth and back without problems. I tried using the XDIV, but that upset the UART so it got completely confused and sent (and received) erroneous data. It would also upset any other timing of course. I find the port I/O solution quite okay. It uses about 18-20 cycles (2.6uS), which is not too bad. But interrupts needs to be disabled as I'm disabling the external memory interface during the card access. My April's fool is working pretty well, although not exactly as shown ;-) Just wait until you see this years version !! /Jesper ----- Original Message ----- From: "Michael Fischer" To: Sent: Thursday, February 12, 2004 10:12 PM Subject: [En-Nut-Discussion] IDE interface > Richard, > > WLAN: This is the problem. The WLAN card use the WAIT signal, for both, IORD > and IOWR. > In the moment I work with a "bus emulation". Some latch to emulate the bus > access, but this takes > about 1.5us .. 2us. > > I have measured the WAIT, on my notebook, and found waits up to 300ns. A > full access CE was up to 600ns. > The atmega is to fast. Without the emulation, it is possible to use the XDIV > functionality of the CPU, > and divide the clock to a lower access. I think this is not a good solution. > > Take a look in the Ethernut CF (WLAN) Interface thread. > > WRITE function: > In the moment on hold, I am waiting on a PCB, Harald? > You will find the source by Ethernut. > > Jesper: > > How is your "April Fool" working? > > Michael > > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From mikec at call-direct.com.au Wed Feb 11 02:48:21 2004 From: mikec at call-direct.com.au (Mike Cornelius) Date: Wed, 11 Feb 2004 12:48:21 +1100 Subject: [En-Nut-Discussion] GPRS PAP problem In-Reply-To: <01c101c3ef25$0a7a6e10$1000a8c0@sonyfrademeyer> Message-ID: <00db01c3f041$222cfce0$2301a8c0@Mike> That's odd, what type of GPRS module are you using? Do you have the APN set correctly ("at+cgdcont") ? I am familiar with the Ericsson GM47 and Nokia 30 modems. Both of these won't start PPP unless the APN is correct. It is of course possible that your module behaves differently. Also with GPRS the PPP session is only between your application and the GPRS module itself (ie the module is the server, the PPP negotiation is NOT done over the air). Most modules (that I've used) will not reject a PPP session at authentication time they simply accept the supplied username and password, and always return OK. Later on once IPCP negotiation begins the module sends both the authentication details and IPCP request to the network at the same time. However I'm not exactly sure of the details of the GPRS side of things (in particular what things MUST the module know before it can start the GPRS authintication phase). The server (module) ACK's your rejection of PCOMP/ACOMP (ie LCP completes) so that doesn't look like the problem to me. 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-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Francois Rademeyer Sent: Tuesday, February 10, 2004 2:55 AM To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] GPRS PAP problem Hi all, Firstly there seems to be a bug in the latest "lcpout.c" file. The line : if ((nb = NutNetBufAlloc(0, NBAF_APPLICATION, rejected ? 6 : 12)) != 0) { should be: if ((nb = NutNetBufAlloc(0, NBAF_APPLICATION, rejected ? 12 : 6)) != 0) { My real problem is that PAP authentication messages seem to be ignored by my GPRS server. The server requires a blank username and password. I have tried blank. I have tried passwords. I have even tried rejecting the (AUTH=0xC023) request from the server. Still I'm being ignored (except for the latter where I get a TERMREQ when it is time for IPCP negotiation). Has anyone experienced this? Could it be that the server is speechless without PCOMP and ACOMP? Thanks in advance for any help. Cheers, Francois Rademeyer Here is a shortened version of my PPP debug output for a blank id/password: PPP < [LCP-1 CONFREQ (ACCM = 0x000A000)] PPP > [LCP-1 CONFREQ (MRU=1500)(ACCM = 0x0000000)(PCOMP)(ACOMP)(AUTH=0xC023)] PPP < [LCP-1 CONFREJ (PCOMP)(ACOMP)] PPP > [LCP-1 CONFACK (ACCM = 0x000A000)] PPP > [LCP-2 CONFREQ (MRU=1500)(ACCM = 0x0000000)(AUTH=0xC023)] PPP < [LCP-2 CONFACK (MRU=1500)(ACCM = 0x0000000)(AUTH=0xC023)] PPP < [PAP-3 AUTHREQ] ... 5 second delay PPP < [PAP-3 AUTHREQ] ... 5 second delay PPP < [PAP-3 AUTHREQ] ... 5 second delay PPP < [PAP-3 AUTHREQ] ... 5 second delay PPP < [PAP-3 AUTHREQ] ... 5 second delay PPP < [PAP-3 AUTHREQ] ... no auth reply received (timeout) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040211/e35d9f4c/attachment.html From harald.kipp at egnite.de Fri Feb 13 15:14:17 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Fri, 13 Feb 2004 15:14:17 +0100 Subject: [En-Nut-Discussion] Interrupting NutTcpSend/Receive from other thread In-Reply-To: References: <5.1.1.6.0.20040212210336.0323bd50@egnite.de> <5.1.1.6.0.20040212210336.0323bd50@egnite.de> Message-ID: <5.1.1.6.0.20040213150815.032dbde8@egnite.de> At 22:43 12.02.2004 +0100, you wrote: > > NutTcpCloseSocket? > >Almost, but that doesn't relieve me from notifying the threads blocking >on NutTcpSend/Receive, does it? Ah, that may happen later automatically If it works as intended, the close will broadcast an event to all waiting threads. But not fully sure after later mods done to these part. Some waiting loops may reenter the NutEventWait, if the action (characters received, connection established) didn't happen. These loops should check the socket status and quit the loop, if it's not in established state. If it fails, we should correct the loops. Generally calling NutTcpCloseSocket() is the correct way to terminate the receiver thread, IMHO. Harald From harald.kipp at egnite.de Fri Feb 13 15:30:53 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Fri, 13 Feb 2004 15:30:53 +0100 Subject: [En-Nut-Discussion] Improved RTL8019AS Driver Message-ID: <5.1.1.6.0.20040213152350.0346c1c0@egnite.de> Bengt Florin contributed an improved Ethernet driver for the Realtek chip. It's available for download here: http://www.ethernut.de/en/projects.html I didn't commit it to CVS now, because it's a kind of basic function and may introduce really weird problems. Please report, if this works for you. I'll also check it here and commit it then. Many thanks to Bent for this time consuming work. I know what I'm talking about. The RTL is a really picky chip and consumed days of my live. Harald From damian at commtech.com.au Mon Feb 16 05:28:34 2004 From: damian at commtech.com.au (Damian Slee) Date: Mon, 16 Feb 2004 12:28:34 +0800 Subject: [En-Nut-Discussion] Improved RTL8019AS Driver Message-ID: Working here with ping -l 60000, whereas the old was rebooting at about ping -l 6500. Have also got latest CVS. Adding a couple of features to our configuration, so will report back in a week after this and the new driver have had some testing. -----Original Message----- From: Harald Kipp [mailto:harald.kipp at egnite.de] Sent: Friday, 13 February 2004 10:31 PM To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] Improved RTL8019AS Driver Bengt Florin contributed an improved Ethernet driver for the Realtek chip. It's available for download here: http://www.ethernut.de/en/projects.html I didn't commit it to CVS now, because it's a kind of basic function and may introduce really weird problems. Please report, if this works for you. I'll also check it here and commit it then. Many thanks to Bent for this time consuming work. I know what I'm talking about. The RTL is a really picky chip and consumed days of my live. Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From damian at commtech.com.au Mon Feb 16 09:15:32 2004 From: damian at commtech.com.au (Damian Slee) Date: Mon, 16 Feb 2004 16:15:32 +0800 Subject: [En-Nut-Discussion] Uart and flow control Message-ID: Hi all, Should uartavr.h be used or usartavr.h for RTS/CTS flow control or XON/XOFF. Usartavr looks more complete, but how do I open that device? I use this for Uart1; NutRegisterDevice(&devUart1, 0, 0); g_rs232 = fopen("uart1", "r+b"); fileno = _fileno(g_rs232); I notice the code in uartavr.c has this, which is obviosly wrong. Look like a copyn'paste from UART_SETLOCALECHO. case UART_SETFLOWCONTROL: if (bv) dcb->dcb_modeflags |= UART_MF_LOCALECHO; else dcb->dcb_modeflags &= ~UART_MF_LOCALECHO; break; case UART_GETFLOWCONTROL: break; Thanks, damian From enut at ixo.de Mon Feb 16 20:33:27 2004 From: enut at ixo.de (Waschk,Kolja) Date: Mon, 16 Feb 2004 20:33:27 +0100 (CET) Subject: [En-Nut-Discussion] Problem with Timers Message-ID: Hi I'm currently hunting for anything that is causing "almost deterministic" lockups of my target. In that state it won't even answer ICMP echo reqs. When interrupted (with avr-gdb / JTAG), gdb most of the time says the interruption occured during NutTimerInsert or some other code in my app that internally is going to use a timer (NutEventWait or similar). So I'm peeking aroung the timer data and code. What I'm wondering is the nutTimerList gdb presents me. Is it okay if it contains self-referencing items, i.e. where tnp == tnp->tn_next? After I put in a real dirty hack to cancel exactly this situation, it came up with referencing loops like shown here: Program received signal SIGINT, Interrupt. 0x0000aa56 in NutTimerInsert (tn=0x80317c) at timer.c:169 169 if (tn->tn_ticks_left < tnp->tn_ticks_left) { (gdb) print tnp $1 = (NUTTIMERINFO *) 0x801825 (gdb) print tnp->tn_next $2 = (NUTTIMERINFO *) 0x80317c (gdb) print tnp->tn_next->tn_next $3 = (NUTTIMERINFO *) 0x801825 (note: same as $1) (gdb) print tnp->tn_next->tn_next->tn_next $4 = (NUTTIMERINFO *) 0x80317c (naturally, same as $2) BTW, saying "almost deterministic" just means that it almost always occurs at about the same time after starting a certain test procedure that causes quite a lot of activity. That's about 5 minutes however. Only a few times it occured a lot earlier. Kolja -- mr. kolja waschk - haubach-39 - 22765 hh - ger phone +49 40 889130-34 - fax -35 - e-mail s.a. From ralph.mason at telogis.com Tue Feb 17 00:00:20 2004 From: ralph.mason at telogis.com (Ralph Mason) Date: Tue, 17 Feb 2004 12:00:20 +1300 Subject: [En-Nut-Discussion] Announce: Nut Hardware Message-ID: <40314B84.4060505@telogis.com> I am pleased to announce new nut compatible hardware. Details from: http://telogis.com/oem_datasheet.pdf It is aimed at telematics applications for OEM's and integrators. The hardware has quite a few nice features, and many NutOS enhancements to support the hardware. It also includes the fabled window simulator. It is shipping now in volume. Regards Ralph From rsloan2003 at hotmail.com Tue Feb 17 05:54:07 2004 From: rsloan2003 at hotmail.com (Richard Sloan) Date: Mon, 16 Feb 2004 23:54:07 -0500 Subject: [En-Nut-Discussion] CPLD equations Message-ID: Does anyone have the CPLD equations/design? I see a schematic to download but its not the guts of the CPLD! Thanks! >From: Ralph Mason >Reply-To: "Ethernut User Chat (English)" >To: en-Nut-Discussion >Subject: [En-Nut-Discussion] Announce: Nut Hardware >Date: Tue, 17 Feb 2004 12:00:20 +1300 > >I am pleased to announce new nut compatible hardware. Details from: > >http://telogis.com/oem_datasheet.pdf > >It is aimed at telematics applications for OEM's and integrators. > >The hardware has quite a few nice features, and many NutOS enhancements to >support the hardware. It also includes the fabled window simulator. > >It is shipping now in volume. > >Regards >Ralph > >_______________________________________________ >En-Nut-Discussion mailing list >En-Nut-Discussion at egnite.de >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca From HeltonGA at aol.com Tue Feb 17 06:36:58 2004 From: HeltonGA at aol.com (HeltonGA at aol.com) Date: Tue, 17 Feb 2004 00:36:58 EST Subject: [En-Nut-Discussion] Ethereal - RTL8019AS data length mismatch Message-ID: <9f.43c8d24b.2d63027a@aol.com> I am a bit confused about some results that I'm seeing in message lengths captured. Using Ethereal to capture traffic, I try to establish a TCP connection using SuperScan4.0. Ethereal reports a TCP message that is 54 bytes ("54 bytes on wire, 54 bytes captured") in length with SYN bit set, Seq Num xxxx, yada, yada, yada. Anyway - why is the message length 54 bytes ? Isn't the minimum message length supposed to be 60 bytes for Ethernet ? Now on to the RTL8019AS. I captured this same message on my development board. When I read the message length from the message header, it is 64 bytes. Subtract out the 4 bytes for the CRC and there are 60 data bytes. Just what I would have expected. When I read out the 60 bytes from the RTL8019 and buffer them, there are 54 bytes that comprise the Ethernet Header, IP Header, and TCP Header (14 + 20 + 20) plus 6 space characters (0x20). Why is there an apparent mismatch in data lengths ? Is Ethereal just ignoring the extra space characters or is the RTL8019 making them up ? By the way, the IP Total Length field is (40). This would account for the IP Header and TCP Header, but would not account for any "extra" spaces (pads) appended as TCP data. Does anyone know what's going on here ? Thanks in advance. Fiz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040217/05d7e9fe/attachment.htm From deoxy at u.washington.edu Tue Feb 17 07:30:15 2004 From: deoxy at u.washington.edu (Amedee Louis Beaudoin) Date: Mon, 16 Feb 2004 22:30:15 -0800 Subject: [En-Nut-Discussion] CPLD equations In-Reply-To: References: Message-ID: <4031B4F7.4010808@u.washington.edu> Hi Richard, The schematic *is* the guts of the CPLD. There is another file that describes the pin to signal mapping, but it may have changed since I sent the design to Harald. I attached the copy I have. Louis Beaudoin Richard Sloan wrote: > Does anyone have the CPLD equations/design? I see a schematic to > download but its not the guts of the CPLD! > > Thanks! > > >> From: Ralph Mason >> Reply-To: "Ethernut User Chat (English)" >> To: en-Nut-Discussion >> Subject: [En-Nut-Discussion] Announce: Nut Hardware >> Date: Tue, 17 Feb 2004 12:00:20 +1300 >> >> I am pleased to announce new nut compatible hardware. Details from: >> >> http://telogis.com/oem_datasheet.pdf >> >> It is aimed at telematics applications for OEM's and integrators. >> >> The hardware has quite a few nice features, and many NutOS >> enhancements to support the hardware. It also includes the fabled >> window simulator. >> >> It is shipping now in volume. >> >> Regards >> Ralph >> >> _______________________________________________ >> En-Nut-Discussion mailing list >> En-Nut-Discussion at egnite.de >> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: enut202.ucf Url: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040216/69d50d4f/attachment.asc From damian at commtech.com.au Tue Feb 17 09:48:21 2004 From: damian at commtech.com.au (Damian Slee) Date: Tue, 17 Feb 2004 16:48:21 +0800 Subject: [En-Nut-Discussion] BugFix: Usart reading Xoff doesn't stop Tx Message-ID: Also can we get the examples changed so they use the new Usart device driver instead of Uart ole one. Ie change NutRegisterDevice(&devUart0, 0, 0); to NutRegisterDevice(&devUsartAvr0, 0, 0); Also I haven't been able to get the driver to send an Xon or Xoff yet, so I'm not sure if this is another problem, or something not set. I would have thought a call to this would send an XON imediately? lTmp = USART_MF_XONXOFF; _ioctl(fileno, UART_SETFLOWCONTROL, &lTmp); Usartavr.c Tx Fix static void AvrUsartTxEmpty(void *arg) { register RINGBUF *rbf = (RINGBUF *) arg; register u_char *cp = rbf->rbf_tail; /* * Process pending software flow controls first. */ if (flow_control & (XON_PENDING | XOFF_PENDING)) { if (flow_control & XON_PENDING) { outb(UDRn, ASCII_XOFF); flow_control |= XOFF_SENT; } else { outb(UDRn, ASCII_XON); flow_control &= ~XOFF_SENT; } flow_control &= ~(XON_PENDING | XOFF_PENDING); return; } // Addition ---> if (flow_control & XOFF_RCVD) { /* * If XOFF has been received, we disable the transmit interrupts * and return without sending anything. */ cbi(UCSRnB, UDRIE); return; } // <---- end of Addition From bengt at florin.se Tue Feb 17 09:50:20 2004 From: bengt at florin.se (Bengt Florin) Date: Tue, 17 Feb 2004 09:50:20 +0100 Subject: [En-Nut-Discussion] Ethereal - RTL8019AS data length mismatch In-Reply-To: <9f.43c8d24b.2d63027a@aol.com> Message-ID: <01cd01c3f533$13c65c90$0205a8c0@hugin> 1. Yes, 60 bytes is min and the driver pads with NUL bytes. Does Ethereal really show the length of the ethernet frame or just the length of the received IP packet? 2. The extra spaces are the padding done by the transmitting host to make if >60 bytes. This padding is not shown in the IP header but only in the ethernet frame, of course. So things are probably quite normal. rgds bengan -----Original Message----- From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de]On Behalf Of HeltonGA at aol.com Sent: den 17 februari 2004 06:37 To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] Ethereal - RTL8019AS data length mismatch I am a bit confused about some results that I'm seeing in message lengths captured. Using Ethereal to capture traffic, I try to establish a TCP connection using SuperScan4.0. Ethereal reports a TCP message that is 54 bytes ("54 bytes on wire, 54 bytes captured") in length with SYN bit set, Seq Num xxxx, yada, yada, yada. Anyway - why is the message length 54 bytes ? Isn't the minimum message length supposed to be 60 bytes for Ethernet ? Now on to the RTL8019AS. I captured this same message on my development board. When I read the message length from the message header, it is 64 bytes. Subtract out the 4 bytes for the CRC and there are 60 data bytes. Just what I would have expected. When I read out the 60 bytes from the RTL8019 and buffer them, there are 54 bytes that comprise the Ethernet Header, IP Header, and TCP Header (14 + 20 + 20) plus 6 space characters (0x20). Why is there an apparent mismatch in data lengths ? Is Ethereal just ignoring the extra space characters or is the RTL8019 making them up ? By the way, the IP Total Length field is (40). This would account for the IP Header and TCP Header, but would not account for any "extra" spaces (pads) appended as TCP data. Does anyone know what's going on here ? Thanks in advance. Fiz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040217/0b827029/attachment.htm From damian at commtech.com.au Tue Feb 17 10:45:23 2004 From: damian at commtech.com.au (Damian Slee) Date: Tue, 17 Feb 2004 17:45:23 +0800 Subject: [En-Nut-Discussion] BugFix: Usart half duplex mode doesn't toggle pin Message-ID: Transmit complete interrupt which is required, is only enabled if halfduplex mode is enabled before the uart is initialised. Normally one would open the device, the call SETFLOWCONTROL, in which case transmit complete interrupt never gets enabled. static int AvrUsartSetFlowControl(u_long flags) { ... #ifdef UART_HDX_BIT /* * Set half duplex mode. */ if (flags & USART_MF_HALFDUPLEX) { /* Register transmit complete interrupt. */ if (NutRegisterIrqHandler(&sig_UART_TRANS, AvrUsartTxComplete, &dcb_usart.dcb_rx_rbf)) { return -1; } /* Initially enable the receiver. */ cbi(UART_HDX_PORT, UART_HDX_BIT); sbi(UART_HDX_DDR, UART_HDX_BIT); hdx_control = 1; //-----> /* Enable transmit complete interrupt. */ sbi(UCSRnB, TXCIE); //<----- } else if (hdx_control) { hdx_control = 0; //-----> /* disable transmit complete interrupt */ cbi(UCSRnB, TXCIE); //<----- /* Deregister transmit complete interrupt. */ NutRegisterIrqHandler(&sig_UART_TRANS, 0, 0); cbi(UART_HDX_DDR, UART_HDX_BIT); } #endif ... } From korbai at axelero.hu Tue Feb 17 12:26:41 2004 From: korbai at axelero.hu (Korbai, Zoltan) Date: Tue, 17 Feb 2004 12:26:41 +0100 Subject: [En-Nut-Discussion] PPP (magic number) NUT-3.4.1-RC1 Message-ID: <000901c3f548$eaebfad0$1802a8c0@work> Hi, I tried this version and found that never PPP connection established via GPRS. If I change the line 168 in NET/lcpout.c from if (rejected) { to if (!rejected) { PPP will be ok. (I checked latest CVS and is the same.) Zoltan From bbuenaobra at nip.upd.edu.ph Wed Feb 18 02:51:02 2004 From: bbuenaobra at nip.upd.edu.ph (Berns J. Buenaobra) Date: Tue, 17 Feb 2004 17:51:02 -0800 Subject: [En-Nut-Discussion] GSM/GPRS Module for Ethernut - good candidate brand needed In-Reply-To: <20040217093432.BA7072F42A5@p15095813.pureserver.info> Message-ID: <000101c3f5c1$ad84a330$3a65a8c0@instru.nip.upd.edu.ph> Hello List: Seems to be that the push at my university instrumentation physics lab is to go Web enabled and Wireless. I do not have experience with interfacing a GSM/GPRS modem to the Ethernut (still on the hump of the learning curve!) I would appreciate some wisdom from experiences of the others in the list. Please email me directly for some shared information specially on the "how to" part of the hardware and code. We would like transmit optical scanned data from out optical set-up from the lab to within a kilometer range by GSM, TCP/IP, GPRS or RF Modem. Many thanks for those who would reply and help. Berns Buenaobra Email: bbuenaobra at nip.upd.edu.ph URL: www.nip.upd.edu.ph/ipl From enut at ixo.de Tue Feb 17 18:53:56 2004 From: enut at ixo.de (Waschk,Kolja) Date: Tue, 17 Feb 2004 18:53:56 +0100 (CET) Subject: [En-Nut-Discussion] Problem with Timers In-Reply-To: References: Message-ID: > I'm currently hunting for anything that is causing "almost deterministic" > lockups of my target. In that state it won't even answer ICMP echo reqs. A little status update regarding this problem: 1. I've merged Bengt's "ruggedized" nicrtl driver with our code. That alone however doesn't fix the lock-ups. Just to make sure it's not the driver. 2. I've added NutEnterCritical/ExitCritical at several places in timer.c, event.c and thread.c and a small "paranoia" fix. Now the test loop that caused lockups after max 3 minutes is active since 25 minutes, and still running As soon as I've sorted out if all of the above actually was necessary for stable performance (and only when it really proved to be more stable), I'll post additional details/patches. Kolja -- mr. kolja waschk - haubach-39 - 22765 hh - ger phone +49 40 889130-34 - fax -35 - e-mail s.a. From michael.s at lfiinternational.com Wed Feb 18 03:57:16 2004 From: michael.s at lfiinternational.com (Michael G. Svob) Date: Tue, 17 Feb 2004 18:57:16 -0800 Subject: [En-Nut-Discussion] Ethernut & DMX In-Reply-To: Message-ID: Greetings, Does anyone have experience using an Ethernut to receive and process DMX lighting signals? I'm using a Maxim MAX3084E RS-485 tranceiver chip feeding into USART 0, with baud rate set to 250K, 8 data bits, no parity, and 2 stop bits. Problem is, I can synch on and receive the data (from a known good DMX source), but the received data is a bit funky. For one thing, the MS bit of the data is always "1", so for example data that should be 1 (0x01) is actually returned as 129 (0x81). Also (ignoring the MS bit), for much (but not all) of the range 0-255, other seemingly random bits seem to get set incorrectly for no apparent reason. For example, the value 20 (binary 0001 0100) is received as both 142 (1000 1110) and 156 (1001 1100). For the record, I've tried different baud rates, number of data bits, number of stop bits, etc., but with no success. For what it's worth, I also get exactly the same results with an STK500 and an ATMega16. Thanks in advance for any help that can be extended. Best Regards, Michael Svob From mikec at call-direct.com.au Wed Feb 18 07:32:06 2004 From: mikec at call-direct.com.au (Mike Cornelius) Date: Wed, 18 Feb 2004 17:32:06 +1100 Subject: [En-Nut-Discussion] Bug In NutThreadCreate Message-ID: <054801c3f5e8$f3e19190$2301a8c0@Mike> Hi All, I have found a bug in NutThreadCreate:- NutEnterCritical(); paddr = (const u_short *) fn; // *KU* fn doesn't contain the entry address // of the thread! /* * Allocate stack and thread info structure in one block. */ if ((threadMem = NutHeapAlloc(stackSize + sizeof(NUTTHREADINFO))) == 0) return 0; The above live should read:- if ((threadMem = NutHeapAlloc(stackSize + sizeof(NUTTHREADINFO))) == 0){ NutExitCritical(); return 0; } Or else if you're out of memory you'll end up with a corrupted stack. 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ From francois at asnone.com Wed Feb 18 07:45:24 2004 From: francois at asnone.com (Francois Rademeyer) Date: Wed, 18 Feb 2004 08:45:24 +0200 Subject: [En-Nut-Discussion] Questions re devUart1 Message-ID: <041b01c3f5ea$ca4afbd0$1b00a8c0@sonyfrademeyer> Hi all, When I change from using devDebug1 to devUart1 for stdout it stops working. Has anyone experienced this? I'm sure it could be one of a multitude of problems. I'm also using the devUart0 driver elsewhere in my program with no problems. Something that is also quite peculiar is that I notice that my .bss segment grows almost 700 bytes in size when doing the above mentioned change. I don't know about other people, but when I have NUTDEBUG enabled the standard 4K memory becomes very small indeed. How do I enable external RAM for .bss and .data when working with Nut-Os? Is there any advantage in using the new usart driver above the uart for standard 8N1 operation? How can I set an already active stream to also output to stdout? Thanks, Francois From francois at asnone.com Wed Feb 18 07:57:05 2004 From: francois at asnone.com (Francois Rademeyer) Date: Wed, 18 Feb 2004 08:57:05 +0200 Subject: [En-Nut-Discussion] HTTP problem Message-ID: <043301c3f5ec$6b3fb4d0$1b00a8c0@sonyfrademeyer> Another problem: When I run an HTTP server across a GPRS connection, i.e. not nearly as fast as Ethernet, I experience errors when using html frames, i.e. when the web browser downloads multiple items simultaneously. I have not started to trace this with a packet sniffer and was just hoping that I'm in luck and someone has a solution ready. I use nearly the same code as the httpd example. Thanks again, Francois From towmeup at as.ro Wed Feb 18 08:12:54 2004 From: towmeup at as.ro (Cosmin Buhu) Date: Wed, 18 Feb 2004 09:12:54 +0200 Subject: [En-Nut-Discussion] Http server References: <041b01c3f5ea$ca4afbd0$1b00a8c0@sonyfrademeyer> Message-ID: <000701c3f5ee$a104be10$1e0a030a@devel> Can someone report how is the httpd working in 3.3.2.1 compared with the latest 3.4.1-rc1 from the ethernut download page (it seems I cannot use the cvs with anonymous)? For me in 3.3.2.1 even with retransmission bug fixed I still have locks (missing images in page for example), and in 3.4 is a bigger mess. Strange for me that browsing from a Linux box and a Windows one makes a difference, from Linux is behaving better. Thanks, Cosmin Buhu From damian at commtech.com.au Wed Feb 18 08:19:28 2004 From: damian at commtech.com.au (Damian Slee) Date: Wed, 18 Feb 2004 15:19:28 +0800 Subject: [En-Nut-Discussion] Http server Message-ID: I do get this a little in old and latest version. Have never investigated. I presume it was a limit of running 2 or 4 connection threads in ethernut, when the browser tries to open 4 at a time I think. -----Original Message----- From: Cosmin Buhu [mailto:towmeup at as.ro] Sent: Wednesday, 18 February 2004 3:13 PM To: Ethernut User Chat (English) Subject: [En-Nut-Discussion] Http server Can someone report how is the httpd working in 3.3.2.1 compared with the latest 3.4.1-rc1 from the ethernut download page (it seems I cannot use the cvs with anonymous)? For me in 3.3.2.1 even with retransmission bug fixed I still have locks (missing images in page for example), and in 3.4 is a bigger mess. Strange for me that browsing from a Linux box and a Windows one makes a difference, from Linux is behaving better. Thanks, Cosmin Buhu _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From towmeup at as.ro Wed Feb 18 08:24:00 2004 From: towmeup at as.ro (Cosmin Buhu) Date: Wed, 18 Feb 2004 09:24:00 +0200 Subject: [En-Nut-Discussion] Http server References: Message-ID: <000501c3f5f0$2df5de70$1e0a030a@devel> Limit where ? Opening 6 or more httpd threads in my code makes no visible improvements. Cosmin ----- Original Message ----- From: "Damian Slee" To: "Ethernut User Chat (English)" Sent: Wednesday, February 18, 2004 9:19 AM Subject: RE: [En-Nut-Discussion] Http server I do get this a little in old and latest version. Have never investigated. I presume it was a limit of running 2 or 4 connection threads in ethernut, when the browser tries to open 4 at a time I think. -----Original Message----- From: Cosmin Buhu [mailto:towmeup at as.ro] Sent: Wednesday, 18 February 2004 3:13 PM To: Ethernut User Chat (English) Subject: [En-Nut-Discussion] Http server Can someone report how is the httpd working in 3.3.2.1 compared with the latest 3.4.1-rc1 from the ethernut download page (it seems I cannot use the cvs with anonymous)? For me in 3.3.2.1 even with retransmission bug fixed I still have locks (missing images in page for example), and in 3.4 is a bigger mess. Strange for me that browsing from a Linux box and a Windows one makes a difference, from Linux is behaving better. Thanks, Cosmin Buhu _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From lightfreakde at yahoo.com Wed Feb 18 09:09:17 2004 From: lightfreakde at yahoo.com (Simon Biniek) Date: Wed, 18 Feb 2004 00:09:17 -0800 (PST) Subject: [En-Nut-Discussion] Ethernut & DMX In-Reply-To: Message-ID: <20040218080917.77105.qmail@web13505.mail.yahoo.com> Hi, try to use only one stop bit in the receiver. This may be nessesary due to the fact, that DMX defines no interbyte gap, so the second stop bit on transmitter side is the gap for the receiver. Simon __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools From robert.hildebrand at ims.fhg.de Wed Feb 18 09:13:11 2004 From: robert.hildebrand at ims.fhg.de (Robert Hildebrand) Date: Wed, 18 Feb 2004 09:13:11 +0100 Subject: AW: [En-Nut-Discussion] Http server In-Reply-To: <000501c3f5f0$2df5de70$1e0a030a@devel> Message-ID: When using opera as browser you can limit the number of maximum pallel connections to one server. That is not the real solution (as only valid for opera and I dind't find a similar setting in other browsers) but maybe you can check the behaviour of the Ethernut better. Robert -----Urspr?ngliche Nachricht----- Von: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Cosmin Buhu Gesendet: Mittwoch, 18. Februar 2004 08:24 An: Ethernut User Chat (English) Betreff: Re: [En-Nut-Discussion] Http server Limit where ? Opening 6 or more httpd threads in my code makes no visible improvements. Cosmin ----- Original Message ----- From: "Damian Slee" To: "Ethernut User Chat (English)" Sent: Wednesday, February 18, 2004 9:19 AM Subject: RE: [En-Nut-Discussion] Http server I do get this a little in old and latest version. Have never investigated. I presume it was a limit of running 2 or 4 connection threads in ethernut, when the browser tries to open 4 at a time I think. -----Original Message----- From: Cosmin Buhu [mailto:towmeup at as.ro] Sent: Wednesday, 18 February 2004 3:13 PM To: Ethernut User Chat (English) Subject: [En-Nut-Discussion] Http server Can someone report how is the httpd working in 3.3.2.1 compared with the latest 3.4.1-rc1 from the ethernut download page (it seems I cannot use the cvs with anonymous)? For me in 3.3.2.1 even with retransmission bug fixed I still have locks (missing images in page for example), and in 3.4 is a bigger mess. Strange for me that browsing from a Linux box and a Windows one makes a difference, from Linux is behaving better. Thanks, Cosmin Buhu _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From towmeup at as.ro Wed Feb 18 09:54:26 2004 From: towmeup at as.ro (Cosmin Buhu) Date: Wed, 18 Feb 2004 10:54:26 +0200 Subject: [En-Nut-Discussion] Http server References: Message-ID: <001a01c3f5fc$d0316e50$1e0a030a@devel> With Opera things are improved but even with only one connection at a time/server enabled with a high stress on ethernut (fast clicking...) it still locks. The same happens with my application and stock httpd example as well. Cosmin ----- Original Message ----- From: "Robert Hildebrand" To: "Ethernut User Chat (English)" Sent: Wednesday, February 18, 2004 10:13 AM Subject: AW: [En-Nut-Discussion] Http server When using opera as browser you can limit the number of maximum pallel connections to one server. That is not the real solution (as only valid for opera and I dind't find a similar setting in other browsers) but maybe you can check the behaviour of the Ethernut better. Robert -----Urspr?ngliche Nachricht----- Von: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Cosmin Buhu Gesendet: Mittwoch, 18. Februar 2004 08:24 An: Ethernut User Chat (English) Betreff: Re: [En-Nut-Discussion] Http server Limit where ? Opening 6 or more httpd threads in my code makes no visible improvements. Cosmin ----- Original Message ----- From: "Damian Slee" To: "Ethernut User Chat (English)" Sent: Wednesday, February 18, 2004 9:19 AM Subject: RE: [En-Nut-Discussion] Http server I do get this a little in old and latest version. Have never investigated. I presume it was a limit of running 2 or 4 connection threads in ethernut, when the browser tries to open 4 at a time I think. -----Original Message----- From: Cosmin Buhu [mailto:towmeup at as.ro] Sent: Wednesday, 18 February 2004 3:13 PM To: Ethernut User Chat (English) Subject: [En-Nut-Discussion] Http server Can someone report how is the httpd working in 3.3.2.1 compared with the latest 3.4.1-rc1 from the ethernut download page (it seems I cannot use the cvs with anonymous)? For me in 3.3.2.1 even with retransmission bug fixed I still have locks (missing images in page for example), and in 3.4 is a bigger mess. Strange for me that browsing from a Linux box and a Windows one makes a difference, from Linux is behaving better. Thanks, Cosmin Buhu _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From harald.kipp at egnite.de Wed Feb 18 11:15:29 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 18 Feb 2004 11:15:29 +0100 Subject: [En-Nut-Discussion] HTTP problem In-Reply-To: <043301c3f5ec$6b3fb4d0$1b00a8c0@sonyfrademeyer> Message-ID: <5.1.1.6.0.20040218110019.01c6e4a8@egnite.de> Hi Francois, HTTP adds some difficulties like parallel connections and connects/disconnects at high rates. All applications we tested with GPRS had been single connections, established for a longer period. What I can say is, that troughput is no real problem, PPP seems to work quite reliable at higher data rates. But parallel connections may disclose bugs, which had been undiscovered during our test. The providers we tried recently didn't route our browser requests via Intranet-DLS-Internet-GPRS-Ethernut. So we only tested connecting the other way round, GPRS->DSL. No idea, why this is routed and DSL->GPRS isn't, because from the IP layers view there is no difference. Modern routers are quite intelligent, though. So this test would require to write a specific application, a multiconnect client, which we don't have right know. I'd welcome, if you are able to further investigate the problem. You can trace Ethernut's TCP traffic, but it requires to have the second UART connected. Let me know, if we can help in any way. Regards, Harald From harald.kipp at egnite.de Wed Feb 18 10:58:10 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 18 Feb 2004 10:58:10 +0100 Subject: [En-Nut-Discussion] Http server In-Reply-To: <001a01c3f5fc$d0316e50$1e0a030a@devel> References: Message-ID: <5.1.1.6.0.20040218104031.01befc60@egnite.de> Hi Cosmin, Every TCP server in the world, even the fastest SUN/IBM/HP or whatever will get in trouble sooner or later. SYN attacks are based on this. Because of memory constraints, Ethernut has no pre-assigned buffers for sockets. So your application has to take care of two things: 1. Do not blindly rely on malloc() being succesfull, like many PC programs do. 2. Delay your server thread if memory becomes low. Ethernut is a very small and very slow system, compared with PCs and larger servers. Compared with other 8-Bit systems, it's exceptionally fast and, if you take care of the advices given above, it works very reliable. Sorry for sounding a bit advertising, but I tried some "competitor" products. Just as an example, the Rabbit stack is very complete and works quite well, but is slower, requires more memory and overruns appear much sooner. The Atmel stack is a nice toy, nothing more. The hardware chip (like the one on the newer Atmel Kit) is even more limited regarding concurrent connections. So please keep in mind, that you are running a system, which is similar to the Apple II or Commodore PET. Regards, Harald From francois at asnone.com Wed Feb 18 11:33:35 2004 From: francois at asnone.com (Francois Rademeyer) Date: Wed, 18 Feb 2004 12:33:35 +0200 Subject: [En-Nut-Discussion] HTTP problem References: <5.1.1.6.0.20040218110019.01c6e4a8@egnite.de> Message-ID: <04ea01c3f60a$aa3239b0$1b00a8c0@sonyfrademeyer> Hi Harald, Thanks for the feedback. > The providers we tried recently didn't route our browser > requests via Intranet-DLS-Internet-GPRS-Ethernut. You have to request a public IP from your provider as they all tend to have the GPRS units behind a firewall. They will most probably give you a new APN, username and password and then also charge you for a static IP. With a single html page and one picture I get an error almost every 5th request. My simple CGI pages have not given any problems yet. I do have logging on the 2nd UART and also use ethereal on the browser side. Regards, Francois ----- Original Message ----- From: "Harald Kipp" To: "Ethernut User Chat (English)" Sent: Wednesday, February 18, 2004 12:15 PM Subject: Re: [En-Nut-Discussion] HTTP problem > Hi Francois, > > HTTP adds some difficulties like parallel connections > and connects/disconnects at high rates. All applications we > tested with GPRS had been single connections, established > for a longer period. > > What I can say is, that troughput is no real problem, PPP > seems to work quite reliable at higher data rates. But > parallel connections may disclose bugs, which had been > undiscovered during our test. > > The providers we tried recently didn't route our browser > requests via Intranet-DLS-Internet-GPRS-Ethernut. So we > only tested connecting the other way round, GPRS->DSL. > No idea, why this is routed and DSL->GPRS isn't, because > from the IP layers view there is no difference. Modern > routers are quite intelligent, though. > > So this test would require to write a specific application, > a multiconnect client, which we don't have right know. > > I'd welcome, if you are able to further investigate the > problem. You can trace Ethernut's TCP traffic, but it > requires to have the second UART connected. Let me know, > if we can help in any way. > > Regards, > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From harald.kipp at egnite.de Wed Feb 18 11:29:23 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 18 Feb 2004 11:29:23 +0100 Subject: [En-Nut-Discussion] Questions re devUart1 In-Reply-To: <041b01c3f5ea$ca4afbd0$1b00a8c0@sonyfrademeyer> Message-ID: <5.1.1.6.0.20040218111634.01c3cfc8@egnite.de> Hi Francois, At 08:45 18.02.2004 +0200, you wrote: >Hi all, > >When I change from using devDebug1 to devUart1 for stdout it stops working. >Has anyone experienced this? I'm sure it could be one of a multitude of >problems. I'm also using the devUart0 driver elsewhere in my program with >no problems. Ah, I see, you are already using UART1. >Something that is also quite peculiar is that I notice that my .bss segment >grows almost 700 bytes in size when doing the above mentioned change. I >don't know about other people, but when I have NUTDEBUG enabled the standard >4K memory becomes very small indeed. How do I enable external RAM for .bss >and .data when working with Nut-Os? NUTDEBUG output may not work with devUartx, some outputs rely on polling output. devUart statically pre-allocates it's buffers, so better use devUsart. For RAM usage: Using more than 4k for bss should be no problem (for ICC, enable the external RAM option). But I think there is a problem when using nearly 4k. >Is there any advantage in using the new usart driver above the uart for >standard 8N1 operation? As mentioned above, it allocates its buffers from heap. But its also slower and increases overall interrupt latency. >How can I set an already active stream to also output to stdout? This is no mailing list for C newbies - go playing with BASIC. :-) freopen should do that: http://www.int.gu.edu.au/courses/2010int/tute04.html Regards, Harald From towmeup at as.ro Wed Feb 18 12:24:12 2004 From: towmeup at as.ro (Cosmin Buhu) Date: Wed, 18 Feb 2004 13:24:12 +0200 Subject: [En-Nut-Discussion] Http server References: <5.1.1.6.0.20040218104031.01befc60@egnite.de> Message-ID: <002401c3f611$bc5cef70$1e0a030a@devel> Thanks Harald. However, I do not use any NutHeapAlloc or equivalents in my test code and I kept the piece of code to delay on low memory (and ram usage shows somewhere to 17K free). On latest trials with opera/2 connections ethereal shows complete locks (no response from ethernut, sometimes stopping in the middle of the page, sometimes after acking the query, sometimes not answering at all), no ping etc. With httpd example from app folder it happens too. Am I completely wrong? Are you running the httpd example trouble free ? Cosmin ----- Original Message ----- From: "Harald Kipp" To: "Ethernut User Chat (English)" Sent: Wednesday, February 18, 2004 11:58 AM Subject: Re: [En-Nut-Discussion] Http server > Hi Cosmin, > > Every TCP server in the world, even the fastest SUN/IBM/HP > or whatever will get in trouble sooner or later. SYN attacks > are based on this. > > Because of memory constraints, Ethernut has no pre-assigned > buffers for sockets. So your application has to take care > of two things: > > 1. Do not blindly rely on malloc() being succesfull, like > many PC programs do. > > 2. Delay your server thread if memory becomes low. > > Ethernut is a very small and very slow system, compared > with PCs and larger servers. Compared with other 8-Bit > systems, it's exceptionally fast and, if you take care > of the advices given above, it works very reliable. > > Sorry for sounding a bit advertising, but I tried some > "competitor" products. Just as an example, the Rabbit stack > is very complete and works quite well, but is slower, > requires more memory and overruns appear much sooner. > The Atmel stack is a nice toy, nothing more. The hardware > chip (like the one on the newer Atmel Kit) is even more > limited regarding concurrent connections. > > So please keep in mind, that you are running a system, > which is similar to the Apple II or Commodore PET. > > Regards, > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From harald.kipp at egnite.de Wed Feb 18 12:48:10 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 18 Feb 2004 12:48:10 +0100 Subject: [En-Nut-Discussion] Http server In-Reply-To: <002401c3f611$bc5cef70$1e0a030a@devel> References: <5.1.1.6.0.20040218104031.01befc60@egnite.de> Message-ID: <5.1.1.6.0.20040218123550.031c78f8@egnite.de> Cosmin, Even if you don't use malloc or NutHeapAlloc directly, it may be used indirectly, like fopen (which returns a NULL pointer in that case) etc. The http sample works here as designed. After some successive requests, the connect hangs for some seconds and continues as soon as Ethernut releases the previously allocated sockets. I'm using Mozilla. Anyone else using Opera? I can hardly believe, that this browser causes the problem...but who knows... It may hang for a few seconds. But it should continue and should _always_ respond to pings. As far as I unterstood, you need to reset the board after the problem appears, right? Does it happen with the original httpd sample on all pages? I'm specially interested in the socket list. Can you try this, please? Can you please specify, what board you are using? And what compiler version? I'll try to reproduce it here. Regards, Harald From francois at asnone.com Wed Feb 18 12:51:25 2004 From: francois at asnone.com (Francois Rademeyer) Date: Wed, 18 Feb 2004 13:51:25 +0200 Subject: [En-Nut-Discussion] Questions re devUart1 References: <5.1.1.6.0.20040218111634.01c3cfc8@egnite.de> Message-ID: <051b01c3f615$89b2ac00$1b00a8c0@sonyfrademeyer> Thanks. Not soon after I sent the mail I discovered the problem: devDebug defaults to a baudrate of 115200 and devUart not. > For RAM usage: Using more than 4k for bss should be > no problem (for ICC, enable the external RAM option). > But I think there is a problem when using nearly 4k. How do GCC users achieve this? > This is no mailing list for C newbies - go playing > with BASIC. :-) I'm just a lazy C++ programmer. When you have driven a Porsche for so long it's quite tiresome to find your way around a Trabant. (-: A common nemesis of many folks have once made a very true statement: "Most engineers use a subset of C plus plus called C plus plus minus minus". Cheers, Francois From harald.kipp at egnite.de Wed Feb 18 13:35:55 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 18 Feb 2004 13:35:55 +0100 Subject: [En-Nut-Discussion] Questions re devUart1 In-Reply-To: <051b01c3f615$89b2ac00$1b00a8c0@sonyfrademeyer> References: <5.1.1.6.0.20040218111634.01c3cfc8@egnite.de> Message-ID: <5.1.1.6.0.20040218132432.01c34e78@egnite.de> At 13:51 18.02.2004 +0200, you wrote: >Thanks. > >Not soon after I sent the mail I discovered the problem: devDebug defaults >to a baudrate of 115200 and devUart not. Oops! Exactly the same happened to me two days ago. I tried to test an overclocked Ethernut, running at 18.432 MHz. All baudrate settings failed until I discovered the hardcoded baudrate. For devDebug0 it should be static int DebugIOCtl(NUTDEVICE * dev, int req, void *conf) { if(req == UART_SETSPEED) { outb(UBRR, (u_char) ((((2UL * NutGetCpuClock()) / (*((u_long *)conf) * 16UL)) + 1UL) / 2UL) - 1); return 0; } return -1; } > > For RAM usage: Using more than 4k for bss should be > > no problem (for ICC, enable the external RAM option). > > But I think there is a problem when using nearly 4k. >How do GCC users achieve this? It is fixed in the linker script. If I remember correctly, GCC assumes 64k RAM, so no change should be required. Last time I tried to verify what's going on in case bss ends near below 4k, I ran into the problem of avr-objcopy crashes. Unable to find out, why this happened, I tried to get the source...later find out I need to do the whole toolchain...updated Cygwin... etc...etc...and my day was gone. > > This is no mailing list for C newbies - go playing > > with BASIC. :-) >I'm just a lazy C++ programmer. When you have driven a Porsche for so long >it's quite tiresome to find your way around a Trabant. (-: A common nemesis >of many folks have once made a very true statement: "Most engineers use a >subset of C plus plus called C plus plus minus minus". Too true...or...MSC++, if you look to all the "so called C++" code in the net. uisp is one of the really bad examples (Sorry Ted, I know it's not your code). Harald From towmeup at as.ro Wed Feb 18 13:45:39 2004 From: towmeup at as.ro (Cosmin Buhu) Date: Wed, 18 Feb 2004 14:45:39 +0200 Subject: [En-Nut-Discussion] Http server References: <5.1.1.6.0.20040218104031.01befc60@egnite.de> <5.1.1.6.0.20040218123550.031c78f8@egnite.de> Message-ID: <003401c3f61d$1da9fd30$1e0a030a@devel> Yes it does happen with the socket cgi and other too, static or cgi. And yes, a reset is the only cure. To be sure I made a fresh reinstall of 332. The same. As you said from time to time after a few secs it recovers but also from time to time doesn't, most of them after acking the packet with get. So, board 1.3F, sw 332, avr-gcc from winavr-20030913. 10. network class, 255.0.0.0 mask, also tried with ethernut cabled with one PC only. The things happen with IE, Opera, windows, linux. Cosmin ----- Original Message ----- From: "Harald Kipp" To: "Ethernut User Chat (English)" Sent: Wednesday, February 18, 2004 1:48 PM Subject: Re: [En-Nut-Discussion] Http server > Cosmin, > > Even if you don't use malloc or NutHeapAlloc directly, > it may be used indirectly, like fopen (which returns > a NULL pointer in that case) etc. > > The http sample works here as designed. After some > successive requests, the connect hangs for some seconds > and continues as soon as Ethernut releases the > previously allocated sockets. I'm using Mozilla. > > Anyone else using Opera? I can hardly believe, that > this browser causes the problem...but who knows... > > It may hang for a few seconds. But it should continue > and should _always_ respond to pings. As far as I > unterstood, you need to reset the board after the > problem appears, right? > > Does it happen with the original httpd sample on > all pages? I'm specially interested in the socket > list. Can you try this, please? > > Can you please specify, what board you are using? > And what compiler version? I'll try to reproduce it > here. > > Regards, > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From enut at ixo.de Wed Feb 18 14:16:48 2004 From: enut at ixo.de (Waschk,Kolja) Date: Wed, 18 Feb 2004 14:16:48 +0100 (CET) Subject: [En-Nut-Discussion] Problem with Timers In-Reply-To: References: Message-ID: > 2. I've added NutEnterCritical/ExitCritical at several places in timer.c, > event.c and thread.c and a small "paranoia" fix. Hm, it all turned out to be a "RTFM" problem. No OS fix needed: I failed to disable interrupts in my app before calling NutEvent*Async() routines (The API documentation mentions this requirement, although not boldly enough for me to read it...). Adding Enter/ExitCritical _there_ fixed all problems. Kolja -- mr. kolja waschk - haubach-39 - 22765 hh - ger phone +49 40 889130-34 - fax -35 - e-mail s.a. From harald.kipp at egnite.de Wed Feb 18 20:07:00 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 18 Feb 2004 20:07:00 +0100 Subject: [En-Nut-Discussion] CPLD equations In-Reply-To: Message-ID: <5.1.1.6.0.20040218200138.01bd5290@egnite.de> Oops! My fault. This archive contained the _Eagle_ Schematic I send to Louis to update pin assignments, not the Xilinx schematic file. Thanks to Michael Fischer, who detected this. The archive has been updated. I additionally added the user constraint file. Sorry for the confusion, Harald At 23:54 16.02.2004 -0500, you wrote: >Does anyone have the CPLD equations/design? I see a schematic to download >but its not the guts of the CPLD! > >Thanks! From olischulz at web.de Wed Feb 18 21:20:07 2004 From: olischulz at web.de (Oliver Schulz) Date: Wed, 18 Feb 2004 21:20:07 +0100 Subject: AW: [En-Nut-Discussion] Bug In NutThreadCreate In-Reply-To: <054801c3f5e8$f3e19190$2301a8c0@Mike> Message-ID: <000401c3f65c$9a9cb050$5b42a8c0@ose.de> Yes, sir. You're right. I already commited the bugfixes to CVS in HEAD and nut-3_4-release Cheers, Oliver. > -----Ursprungliche Nachricht----- > Von: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Mike > Cornelius > Gesendet: Mittwoch, 18. Februar 2004 07:32 > An: en-Nut-Discussion at Egnite. De > Betreff: [En-Nut-Discussion] Bug In NutThreadCreate > > > Hi All, > > I have found a bug in NutThreadCreate:- > > NutEnterCritical(); > paddr = (const u_short *) fn; // *KU* fn doesn't > contain the entry > address > // of the thread! > /* > * Allocate stack and thread info structure in one block. > */ > if ((threadMem = NutHeapAlloc(stackSize + > sizeof(NUTTHREADINFO))) == 0) > return 0; > > The above live should read:- > if ((threadMem = NutHeapAlloc(stackSize + > sizeof(NUTTHREADINFO))) == 0){ > NutExitCritical(); > return 0; > } > > Or else if you're out of memory you'll end up with a corrupted stack. > > 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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~~~ > ~~~ > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From olischulz at web.de Wed Feb 18 23:41:38 2004 From: olischulz at web.de (Oliver Schulz) Date: Wed, 18 Feb 2004 23:41:38 +0100 Subject: [En-Nut-Discussion] Http server In-Reply-To: <003401c3f61d$1da9fd30$1e0a030a@devel> Message-ID: <000501c3f670$5f74b540$5b42a8c0@ose.de> Hi Cosmin, Since I cannot yet reproduce this lockup with my system, please do me a favour. Add the following lines in app/httpd/httpserv.c in function THREAD(service,...) just before the call to NutTcpAccept: u_long ul; ul = 3000; NutTcpSetSockOpt (sock, SO_SNDTIMEO, &ul, sizeof(ul)); ...and test again. Cheers, Oliver. > -----Urspr?ngliche Nachricht----- > Von: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Cosmin Buhu > Gesendet: Mittwoch, 18. Februar 2004 13:46 > An: Ethernut User Chat (English) > Betreff: Re: [En-Nut-Discussion] Http server > > > > Yes it does happen with the socket cgi and other too, static > or cgi. And yes, a reset is the only cure. > To be sure I made a fresh reinstall of 332. The same. As you > said from time to time after a few secs it recovers but also from > time to time doesn't, most of them after acking the packet with get. > So, board 1.3F, sw 332, avr-gcc from winavr-20030913. > 10. network class, 255.0.0.0 mask, also tried with > ethernut cabled with > one PC only. > The things happen with IE, Opera, windows, linux. > > Cosmin > > > > ----- Original Message ----- > From: "Harald Kipp" > To: "Ethernut User Chat (English)" > Sent: Wednesday, February 18, 2004 1:48 PM > Subject: Re: [En-Nut-Discussion] Http server > > > > Cosmin, > > > > Even if you don't use malloc or NutHeapAlloc directly, > > it may be used indirectly, like fopen (which returns > > a NULL pointer in that case) etc. > > > > The http sample works here as designed. After some > > successive requests, the connect hangs for some seconds > > and continues as soon as Ethernut releases the > > previously allocated sockets. I'm using Mozilla. > > > > Anyone else using Opera? I can hardly believe, that > > this browser causes the problem...but who knows... > > > > It may hang for a few seconds. But it should continue > > and should _always_ respond to pings. As far as I > > unterstood, you need to reset the board after the > > problem appears, right? > > > > Does it happen with the original httpd sample on > > all pages? I'm specially interested in the socket > > list. Can you try this, please? > > > > Can you please specify, what board you are using? > > And what compiler version? I'll try to reproduce it > > here. > > > > Regards, > > Harald > > > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From towmeup at as.ro Thu Feb 19 06:43:25 2004 From: towmeup at as.ro (Cosmin Buhu) Date: Thu, 19 Feb 2004 07:43:25 +0200 Subject: [En-Nut-Discussion] Http server References: <000501c3f670$5f74b540$5b42a8c0@ose.de> Message-ID: <003101c3f6ab$4b2d3400$1e0a030a@devel> I have both read and write timeouts in my application from start. In the httpd example makes no difference. Most times locks after "[x] Connected 2xxxx", other times with "Creating socket failed", after just reported 24xxx bytes free. Can be a problem with the SRAM ? I'll try today with -DNUTDEBUG but I'm afraid the findings will be null. Thanks, Cosmin ----- Original Message ----- From: "Oliver Schulz" To: "'Ethernut User Chat (English)'" Sent: Thursday, February 19, 2004 12:41 AM Subject: Re: [En-Nut-Discussion] Http server Hi Cosmin, Since I cannot yet reproduce this lockup with my system, please do me a favour. Add the following lines in app/httpd/httpserv.c in function THREAD(service,...) just before the call to NutTcpAccept: u_long ul; ul = 3000; NutTcpSetSockOpt (sock, SO_SNDTIMEO, &ul, sizeof(ul)); ...and test again. Cheers, Oliver. > -----Urspr?ngliche Nachricht----- > Von: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Cosmin Buhu > Gesendet: Mittwoch, 18. Februar 2004 13:46 > An: Ethernut User Chat (English) > Betreff: Re: [En-Nut-Discussion] Http server > > > > Yes it does happen with the socket cgi and other too, static > or cgi. And yes, a reset is the only cure. > To be sure I made a fresh reinstall of 332. The same. As you > said from time to time after a few secs it recovers but also from > time to time doesn't, most of them after acking the packet with get. > So, board 1.3F, sw 332, avr-gcc from winavr-20030913. > 10. network class, 255.0.0.0 mask, also tried with > ethernut cabled with > one PC only. > The things happen with IE, Opera, windows, linux. > > Cosmin > > > > ----- Original Message ----- > From: "Harald Kipp" > To: "Ethernut User Chat (English)" > Sent: Wednesday, February 18, 2004 1:48 PM > Subject: Re: [En-Nut-Discussion] Http server > > > > Cosmin, > > > > Even if you don't use malloc or NutHeapAlloc directly, > > it may be used indirectly, like fopen (which returns > > a NULL pointer in that case) etc. > > > > The http sample works here as designed. After some > > successive requests, the connect hangs for some seconds > > and continues as soon as Ethernut releases the > > previously allocated sockets. I'm using Mozilla. > > > > Anyone else using Opera? I can hardly believe, that > > this browser causes the problem...but who knows... > > > > It may hang for a few seconds. But it should continue > > and should _always_ respond to pings. As far as I > > unterstood, you need to reset the board after the > > problem appears, right? > > > > Does it happen with the original httpd sample on > > all pages? I'm specially interested in the socket > > list. Can you try this, please? > > > > Can you please specify, what board you are using? > > And what compiler version? I'll try to reproduce it > > here. > > > > Regards, > > Harald > > > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From towmeup at as.ro Thu Feb 19 07:39:15 2004 From: towmeup at as.ro (Cosmin Buhu) Date: Thu, 19 Feb 2004 08:39:15 +0200 Subject: [En-Nut-Discussion] Http server References: <000501c3f670$5f74b540$5b42a8c0@ose.de> Message-ID: <001001c3f6b3$18f082a0$1e0a030a@devel> Me again, I found from heap tracing that I have MEMCORR-, MEMNULL and TWICE problems. Right before ethernut locks. Most frequently MEMCORR-. What can cause heap corruption ? Thanks, Cosmin ----- Original Message ----- From: "Oliver Schulz" To: "'Ethernut User Chat (English)'" Sent: Thursday, February 19, 2004 12:41 AM Subject: Re: [En-Nut-Discussion] Http server Hi Cosmin, Since I cannot yet reproduce this lockup with my system, please do me a favour. Add the following lines in app/httpd/httpserv.c in function THREAD(service,...) just before the call to NutTcpAccept: u_long ul; ul = 3000; NutTcpSetSockOpt (sock, SO_SNDTIMEO, &ul, sizeof(ul)); ...and test again. Cheers, Oliver. From damian at commtech.com.au Thu Feb 19 07:50:46 2004 From: damian at commtech.com.au (Damian Slee) Date: Thu, 19 Feb 2004 14:50:46 +0800 Subject: [En-Nut-Discussion] Http server Message-ID: Not big enough stack on all of the threads? -----Original Message----- From: Cosmin Buhu [mailto:towmeup at as.ro] Sent: Thursday, 19 February 2004 2:39 PM To: Ethernut User Chat (English) Subject: Re: [En-Nut-Discussion] Http server Me again, I found from heap tracing that I have MEMCORR-, MEMNULL and TWICE problems. Right before ethernut locks. Most frequently MEMCORR-. What can cause heap corruption ? Thanks, Cosmin ----- Original Message ----- From: "Oliver Schulz" To: "'Ethernut User Chat (English)'" Sent: Thursday, February 19, 2004 12:41 AM Subject: Re: [En-Nut-Discussion] Http server Hi Cosmin, Since I cannot yet reproduce this lockup with my system, please do me a favour. Add the following lines in app/httpd/httpserv.c in function THREAD(service,...) just before the call to NutTcpAccept: u_long ul; ul = 3000; NutTcpSetSockOpt (sock, SO_SNDTIMEO, &ul, sizeof(ul)); ...and test again. Cheers, Oliver. _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From towmeup at as.ro Thu Feb 19 08:03:46 2004 From: towmeup at as.ro (Cosmin Buhu) Date: Thu, 19 Feb 2004 09:03:46 +0200 Subject: [En-Nut-Discussion] Http server References: Message-ID: <001301c3f6b6$84b94140$1e0a030a@devel> Nope. Increasing at a huge 2048/thread, still having MEMCORR-. Cosmin ----- Original Message ----- From: "Damian Slee" To: "Ethernut User Chat (English)" Sent: Thursday, February 19, 2004 8:50 AM Subject: RE: [En-Nut-Discussion] Http server Not big enough stack on all of the threads? -----Original Message----- From: Cosmin Buhu [mailto:towmeup at as.ro] Sent: Thursday, 19 February 2004 2:39 PM To: Ethernut User Chat (English) Subject: Re: [En-Nut-Discussion] Http server Me again, I found from heap tracing that I have MEMCORR-, MEMNULL and TWICE problems. Right before ethernut locks. Most frequently MEMCORR-. What can cause heap corruption ? Thanks, Cosmin ----- Original Message ----- From: "Oliver Schulz" To: "'Ethernut User Chat (English)'" Sent: Thursday, February 19, 2004 12:41 AM Subject: Re: [En-Nut-Discussion] Http server Hi Cosmin, Since I cannot yet reproduce this lockup with my system, please do me a favour. Add the following lines in app/httpd/httpserv.c in function THREAD(service,...) just before the call to NutTcpAccept: u_long ul; ul = 3000; NutTcpSetSockOpt (sock, SO_SNDTIMEO, &ul, sizeof(ul)); ...and test again. Cheers, Oliver. _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From Brett.Abbott at digital-telemetry.com Thu Feb 19 20:23:49 2004 From: Brett.Abbott at digital-telemetry.com (Brett Abbott) Date: Fri, 20 Feb 2004 08:23:49 +1300 Subject: [En-Nut-Discussion] Http server Message-ID: <40350D45.8060903@digital-telemetry.com> Cosmin A couple of ideas... 1. Have you tried a second ethernut (just in case). 2. If you have a JTAG unit, trace the location of the heap that is being corrupted - this assumes it reproduces in the same place each time (but can often be engineered this way), place a breakpoint on the data memory at the expected location. Obviously you will see the owner updating the memory, but this will also give you a means to identify what else is changing the memory. This requires you to know what a good heap looks like so you can spot the difference. AVR Studio helps by changing the colour of recently changed memory values. 3. As a third thought, to be ignored if you are using the sample code EXACTLY unchanged, is that it is very easy to reuse the pointer to the device, perhaps initialising or opening it twice, or writing (fprintf) to a pointer/device that hasnt been opened - this generally has fatal consequence matching the symptoms you see. Hope this helps Brett -- ----------------------------------------------------------------- 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 Brett.Abbott at digital-telemetry.com Fri Feb 20 02:22:08 2004 From: Brett.Abbott at digital-telemetry.com (Brett Abbott) Date: Fri, 20 Feb 2004 14:22:08 +1300 Subject: [En-Nut-Discussion] eboot, a tricky bit. Message-ID: <40356140.4000100@digital-telemetry.com> Hi Ive almost completed the port to ICC of eboot but have found a segment of code that has stumped my self taught C programming skills. Could I ask if someone could advise us of the appropriate ICC equivalent? In particular, the line Im having trouble compiling is "sum += *((u_short *) data)++;" Many Thanks, Any help appreciated. Brett from eboot\ip.c: /*! * \brief Calculate the IP checksum over a block of data. * * \param data Pointer to the data block. * \param size Size of the data block. * * \return The checksum in network byte order. */ static u_short IpChkSum(const void *data, u_short size) { register u_long sum = 0; for (;;) { if (size < 2) break; sum += *((u_short *) data)++; size -= 2; } if (size) sum += *(u_char *) data; while ((size = (u_short) (sum >> 16)) != 0) sum = (u_short) sum + size; return (u_short) sum ^ 0xFFFF; } -- ----------------------------------------------------------------- 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/20040220/1847a458/attachment.html From damian at commtech.com.au Fri Feb 20 02:35:24 2004 From: damian at commtech.com.au (Damian Slee) Date: Fri, 20 Feb 2004 09:35:24 +0800 Subject: [En-Nut-Discussion] eboot, a tricky bit. Message-ID: I'm pretty sure its incrementing the contents of memory, not the ptr. the above/below code would help to double check. u_short *tmp; tmp = (u_short *) data; *tmp++; // or (*tmp)++ if it reads better _____ From: Brett Abbott [mailto:Brett.Abbott at digital-telemetry.com] Sent: Friday, 20 February 2004 9:22 AM To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] eboot, a tricky bit. Hi Ive almost completed the port to ICC of eboot but have found a segment of code that has stumped my self taught C programming skills. Could I ask if someone could advise us of the appropriate ICC equivalent? In particular, the line Im having trouble compiling is "sum += *((u_short *) data)++;" Many Thanks, Any help appreciated. Brett from eboot\ip.c: /*! * \brief Calculate the IP checksum over a block of data. * * \param data Pointer to the data block. * \param size Size of the data block. * * \return The checksum in network byte order. */ static u_short IpChkSum(const void *data, u_short size) { register u_long sum = 0; for (;;) { if (size < 2) break; sum += *((u_short *) data)++; size -= 2; } if (size) sum += *(u_char *) data; while ((size = (u_short) (sum >> 16)) != 0) sum = (u_short) sum + size; return (u_short) sum ^ 0xFFFF; } -- ----------------------------------------------------------------- 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/20040220/f1042256/attachment.htm From damian at commtech.com.au Fri Feb 20 02:38:06 2004 From: damian at commtech.com.au (Damian Slee) Date: Fri, 20 Feb 2004 09:38:06 +0800 Subject: [En-Nut-Discussion] eboot, a tricky bit. Message-ID: I should have read on; it looks like the ptr is being incremented u_short *tmp; tmp = (u_short *) data; sum += *tmp; data += sizeof(u_short); _____ From: Damian Slee Sent: Friday, 20 February 2004 9:35 AM To: Brett.Abbott at digital-telemetry.com; Ethernut User Chat (English) Subject: RE: [En-Nut-Discussion] eboot, a tricky bit. I'm pretty sure its incrementing the contents of memory, not the ptr. the above/below code would help to double check. u_short *tmp; tmp = (u_short *) data; *tmp++; // or (*tmp)++ if it reads better _____ From: Brett Abbott [mailto:Brett.Abbott at digital-telemetry.com] Sent: Friday, 20 February 2004 9:22 AM To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] eboot, a tricky bit. Hi Ive almost completed the port to ICC of eboot but have found a segment of code that has stumped my self taught C programming skills. Could I ask if someone could advise us of the appropriate ICC equivalent? In particular, the line Im having trouble compiling is "sum += *((u_short *) data)++;" Many Thanks, Any help appreciated. Brett from eboot\ip.c: /*! * \brief Calculate the IP checksum over a block of data. * * \param data Pointer to the data block. * \param size Size of the data block. * * \return The checksum in network byte order. */ static u_short IpChkSum(const void *data, u_short size) { register u_long sum = 0; for (;;) { if (size < 2) break; sum += *((u_short *) data)++; size -= 2; } if (size) sum += *(u_char *) data; while ((size = (u_short) (sum >> 16)) != 0) sum = (u_short) sum + size; return (u_short) sum ^ 0xFFFF; } -- ----------------------------------------------------------------- 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/20040220/a3ce0fb4/attachment.html From towmeup at as.ro Fri Feb 20 07:03:51 2004 From: towmeup at as.ro (Cosmin Buhu) Date: Fri, 20 Feb 2004 08:03:51 +0200 Subject: [En-Nut-Discussion] Http server References: <40350D45.8060903@digital-telemetry.com> Message-ID: <000501c3f777$50bcb860$1e0a030a@devel> Thanks Brett, For one, hope to test soon. For three, yes the unchanged httpd, on heavy stress (just refresh page in browser quick enough). For two, I haven't a JTAG unit, but hope to buy an Olimex one soon. I tested other apps too, some strange things appeared too (like sockets blocked on send even if there are timeouts set, not returning from unsuccessful dns queries). Hmm, maybe because I'm a self trained programmer. Regards, Cosmin ----- Original Message ----- From: "Brett Abbott" To: Sent: Thursday, February 19, 2004 9:23 PM Subject: RE: [En-Nut-Discussion] Http server > Cosmin > > A couple of ideas... > > 1. Have you tried a second ethernut (just in case). > 2. If you have a JTAG unit, trace the location of the heap that is being > corrupted - this assumes it reproduces in the same place each time (but > can often be engineered this way), place a breakpoint on the data memory > at the expected location. Obviously you will see the owner updating the > memory, but this will also give you a means to identify what else is > changing the memory. This requires you to know what a good heap looks > like so you can spot the difference. AVR Studio helps by changing the > colour of recently changed memory values. > 3. As a third thought, to be ignored if you are using the sample code > EXACTLY unchanged, is that it is very easy to reuse the pointer to the > device, perhaps initialising or opening it twice, or writing (fprintf) > to a pointer/device that hasnt been opened - this generally has fatal > consequence matching the symptoms you see. > > Hope this helps > Brett > > -- > ----------------------------------------------------------------- > 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.cgi/en-nut-discussion > From HeltonGA at aol.com Fri Feb 20 19:59:26 2004 From: HeltonGA at aol.com (HeltonGA at aol.com) Date: Fri, 20 Feb 2004 13:59:26 EST Subject: [En-Nut-Discussion] TCP connection sequence question Message-ID: <11e.2af65d45.2d67b30e@aol.com> I am having a problem making a TCP connection with my development board and code. This is not an Ethernut problem. Here is the problem. When the client (SuperScan in this case) requests to open a TCP connection, it sends the following information (captured using Ethereal) INFO Field 1089 > http [SYN] Seq=609287992 Ack=0 Win=64240 Len=0 My code's response was: http > 1089 [SYN, ACK] Seq=3094077 Ack=609287993 Win=64240 Len=0 This is what I would have expected from the client to complete the connecton: 1089 > http [ACK] Seq=609287993 Ack=3094078 Win=64240 Len=0 The client should have ACKed my (server's) last Seq number + 1 and repeated the server's last Ack value in it's Seq value. This is based on my understanding of RFC793, pg 31. However, I got this response to my ACK: 1089 > http [SYN] Seq=609287992 Ack=0 Win=64240 Len=0 Is there a problem with SuperScan or is my understanding of the TCP connection sequence incorrect ? Thanks, Fiz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040220/3ab848e4/attachment.htm -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: tcpget2.txt Url: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040220/3ab848e4/attachment.txt From harald.kipp at egnite.de Fri Feb 20 20:32:01 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Fri, 20 Feb 2004 20:32:01 +0100 Subject: [En-Nut-Discussion] TCP connection sequence question In-Reply-To: <11e.2af65d45.2d67b30e@aol.com> Message-ID: <5.1.1.6.0.20040220202951.01c6bbd8@egnite.de> > >However, I got this response to my ACK: >1089 > http [SYN] Seq=609287992 Ack=0 Win=64240 Len=0 It simply didn't receive the SYN/ACK and thus repeats the previous SYN. Harald From Brett.Abbott at digital-telemetry.com Sun Feb 22 04:15:03 2004 From: Brett.Abbott at digital-telemetry.com (Brett Abbott) Date: Sun, 22 Feb 2004 16:15:03 +1300 Subject: [En-Nut-Discussion] Where in the CVS is eboot? Message-ID: <40381EB7.3000507@digital-telemetry.com> Hi Ive been looking in the CVS repository for eboot (Ethernut 1 boot loader) but cannot find the latest source. (or any for that matter - just appload which appears to be for Ethernut 2 only). Could someone email me a zip of the latest versions or point me to a copy. Im porting the 3.3.0 version to ICC but want to ensure I have the latest version. This would be much appreciated. Thanks Brett -- ----------------------------------------------------------------- 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 ching at cmeng.com.hk Fri Feb 20 03:05:18 2004 From: ching at cmeng.com.hk (Ching Chi Fai) Date: Fri, 20 Feb 2004 10:05:18 +0800 Subject: [En-Nut-Discussion] The EEPROM was lost? Message-ID: <000801c3f755$fea03960$b401a8c0@cmeng.local> When i download the new HEX to the ethernut board, then all EEPROM was Clear. But our board can not be init. the ethernet port. any body have a sample of the EEPROM, and give help for me? Thanks Ching Chi Fai. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040220/ccd0d5e6/attachment.htm From seek25 at yahoo.com Sun Feb 22 13:52:00 2004 From: seek25 at yahoo.com (Whatever Org) Date: Sun, 22 Feb 2004 04:52:00 -0800 (PST) Subject: [En-Nut-Discussion] rtl8019 driver troubles In-Reply-To: <40381EB7.3000507@digital-telemetry.com> Message-ID: <20040222125200.12984.qmail@web11203.mail.yahoo.com> Hello, I know that Ehernut doesn't use an ISA card, but the init and receive/send must be same. The problem I encounter is that sometimes I read wrong MAC (FF:FF:etc or somehow I left first byte, so 2nd becomes 1st, and so on, last one always beign 0x20, after few resets of NIC and STK500 problem dissapear) and also sometimes packets looks like didn't hit the NIC, I mean the led blinks, no ARP is send and my debug code seems that nothing is received. Also this situation is fixed after few resets. So there must be a bad timing or wrong init sequence? Sometimes, I receive ethernet frame almost fine, except that arp 0x06 type becomes 0x16, and the same for all of them. All things works if I reset few times... It may help if somebody knows ISA IOR/IOW strobes timing, the HARD RESET delay, and also the correct rl8019 init sequence, with delays, if exists, between each pack read/write. All of my code is in ASM, but I have no problem porting from C to ASM :) Digitaly yours, Cornel I. __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools From HeltonGA at aol.com Sun Feb 22 19:14:16 2004 From: HeltonGA at aol.com (HeltonGA at aol.com) Date: Sun, 22 Feb 2004 13:14:16 EST Subject: [En-Nut-Discussion] rtl8019 driver troubles Message-ID: <115.2f145a3f.2d6a4b78@aol.com> I've had similar problems when I was developing my RTL8019AS driver. One important piece of information that was not immediately obvious from the datasheet is the active state of the IOWB and IORB. Looking at the pinout and pin descriptions, you might assume that the active state of these pins are active high. WRONG ! They are in fact active low signals. Look at the timing diagram on page 47 of the datasheet. A few strategically placed "NOP"s can help on timing issues as well. Pay particular attention to T4,T6,T7,T8 timing. When my code was using active high signals for IOWB and IORB, I would get results similar to yours. It sort of worked, but data was sometimes skewed and data was not as expected. This may not solve your problem, but it can't hurt to refer to the datasheet to make sure your driver complys with timing requirements for the 8019. Here is a link to download the latest datasheet. http://www.realtek.com.tw/downloads/downloads1-3.aspx?spec=True& compamodel=RTL8019AS Good Luck, Fiz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040222/80846e2a/attachment.html From bbuenaobra at nip.upd.edu.ph Tue Feb 24 00:13:19 2004 From: bbuenaobra at nip.upd.edu.ph (Berns J. Buenaobra) Date: Mon, 23 Feb 2004 15:13:19 -0800 Subject: [En-Nut-Discussion] How to GPRS using the Ethernet 1.3F board References: <20040221110002.B4D452F42A5@p15095813.pureserver.info> Message-ID: <015d01c3fa62$a08585f0$6565a8c0@instru.nip.upd.edu.ph> Hello: There is a connection merit that outways SMS messaging using GPRS I was told. My question is how do you begin GPRS interfacing the Ethernut? What steps has to be done? Codes to look at? Thanks, Berns B. From simon.clarke217 at ntlworld.com Mon Feb 23 09:51:56 2004 From: simon.clarke217 at ntlworld.com (Simon Clarke) Date: Mon, 23 Feb 2004 08:51:56 -0000 Subject: [En-Nut-Discussion] How to GPRS using the Ethernet 1.3F board References: <20040221110002.B4D452F42A5@p15095813.pureserver.info> <015d01c3fa62$a08585f0$6565a8c0@instru.nip.upd.edu.ph> Message-ID: <00e401c3f9ea$4f7691e0$b57ba8c0@davids2000> ok first off compile ethernut with nutdebug set , i think you said you had an ethernut pcb version 1.3 add -DNUTDEBUG to hwdef entry in userconf.mk and get the pppc.c example working ( appicc directory these are for icc ) connecting to a ppp server i.e a windows 2000 or XP serial port set up for incomming connections using ppp ( easy enough to do ) you may also need to have handshake lines CTS & RTS working too ( modem.h ) ( this is where i am stuck at the moment , i get to the point of ppp configure and it just sits there ! ) so think i need handshake lines then here's the start application done for GPRS you need to decide which gprs phone or module you wish to use , i have a nokia 6310i and a dlr-3p cable to connect to a serial port ( not usb version ) or use a GPRS Module such as a Siemens MC45 , Sony erricson GM47 both are known to work fine with ethernut . which ever gprs provider you use ( let me know which one ) you need to ring them and get GPRS internet connection enabled ( not done by default ) also ask them for a permanant IP Address ( their may be a charge additional to normal ) as most GPRS phones are held behind a firewall .( you could leave this till later not sure if we need it yet ) ----- Original Message ----- From: "Berns J. Buenaobra" To: Sent: Monday, February 23, 2004 11:13 PM Subject: [En-Nut-Discussion] How to GPRS using the Ethernet 1.3F board > Hello: > > There is a connection merit that outways SMS messaging using GPRS I was > told. My question is how do you begin GPRS interfacing the Ethernut? What > steps has to be done? Codes to look at? > > Thanks, > > Berns B. > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: GPRS-PPP.C Url: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040223/99952619/attachment.pot From bbuenaobra at nip.upd.edu.ph Tue Feb 24 04:08:47 2004 From: bbuenaobra at nip.upd.edu.ph (Berns J. Buenaobra) Date: Mon, 23 Feb 2004 19:08:47 -0800 Subject: [En-Nut-Discussion] Re: En-Nut-Discussion Digest, Vol 4, Issue 29 References: <20040223110004.A570C2F42A3@p15095813.pureserver.info> Message-ID: <000e01c3fa83$84e202d0$6565a8c0@instru.nip.upd.edu.ph> Great thanks! Looks like a fine code. Berns B. From damian at commtech.com.au Tue Feb 24 04:41:07 2004 From: damian at commtech.com.au (Damian Slee) Date: Tue, 24 Feb 2004 11:41:07 +0800 Subject: [En-Nut-Discussion] fix for - Realm: cgi"Content-Type: text/html Message-ID: httpd.c needed a \r\n at the end of auth_fmt_P[]. Otherwise "Content-Type: text/html" gets appended to the line, not on a new line. void NutHttpSendError(FILE * stream, REQUEST * req, int status) { .. static prog_char auth_fmt_P[] = "WWW-Authenticate: Basic realm=\"%s\"\r\n"; Now displays "cgi-bin" as the realm, not "cgi"Content-Type: text/html" in internet explorer. From damian at commtech.com.au Tue Feb 24 09:05:36 2004 From: damian at commtech.com.au (Damian Slee) Date: Tue, 24 Feb 2004 16:05:36 +0800 Subject: [En-Nut-Discussion] Http server - ethereal Message-ID: I have been looking at this in more detail today, cause I have had the same problem as Cosmin since I started using ethernut 6+months ago. Running latest CVS, and new realtek driver. I had this problem before the new realtek driver. I have a frames page with 3 sections in it, so 3 html files + frame setup html file. Only text content + forms on the pages. The problem is that the main frame with a form on it sits there trying to load for about 20 seconds, then it loads. I have traced this with Ethereal. If I click on one of my menu links in the left frame, forcing browser to open new connection, the form loads imediately. Originally I though this was cause I was only running 2 http threads, but changing this to 4 or 8 makes no difference. Like Cosmin indicated last week. Even stranger, after not being able to solve it, I enabled NUTDEBUG on tcp. Got some nice debug out the serial port. I can no longer replicate the problem. Remove NUTDEBUG, and problem comes back. I don't think it is low memory causing this, it would be worse with NUTDEBUG wouldn't it? I captured with etherreal, powered on ethernut, then opened browser and replicated the problem. Stop capture 20+ seconds later, once it had fully loaded with no intervention. Capture showed; (anyone know how to export to txt file in ethereal?) (PC port number in brackets) (I have left off the trailing ACK, FIN ACK) (2104) TCP syn sent by PC to ethernut for first HTTP request ARP lookup by ethernut (2104) SYN ACK sent back to PC, and ACK back again (2104) Data (2104) FIN ACK (2106) TCP syn sent by PC (2106) SYN ACK sent back to PC, , and ACK back again (2106) data (2108) TCP syn sent by PC (2109) TCP syn sent by PC (this appears to get lost) (2106) FIN ACK (2108) SYN ACK sent back to PC, , and ACK back again (2108) data (3 seconds later) (2109) TCP syn sent by PC (this appears to get lost, again) (6 seconds later) (2109) TCP syn sent by PC (this appears to get lost, again) (12 seconds later, error must be reported back to browser after 3 Syn timeouts) (browser gives up on port 2109, closes socket and tries open another socket) (2110) TCP syn sent by PC ~1 millisecond later (2110) SYN ACK sent back to PC, , and ACK back again (2110) data < page loaded completely > Repeatable every time from power on. Sometimes while refreshing. ----------------------------------------------------------- These are the scenarios as I see it? 1.) If the first (2109) Syn got lost Why don't the 2nd or 3rd Syn, get Syn,Acked? 2.) Low memory. Then 9 seconds later the other threads have well and truly stopped, and memory been freed, why shouldn't it be able to handle the Syn's being sent then? 3.) Syn Ack from ethernut got lost, and no further Syn Acks are sent? I not sure, should another Syn Ack be sent in reponse to a received Syn, 3 and 9 seconds later? 4.) Its like that port number gets barred. Any ideas on how to move forward on this? From francois at asnone.com Tue Feb 24 14:15:36 2004 From: francois at asnone.com (Francois Rademeyer) Date: Tue, 24 Feb 2004 15:15:36 +0200 Subject: [En-Nut-Discussion] Thread stack Message-ID: <06e901c3fad8$4b341410$1b00a8c0@sonyfrademeyer> Hi everyone, I have some stupid questions: Lately I have become very confused with all the GCC, AVR & NUT memories. I am trying to find a good balance for the stack size specified when creating threads. Except for all the registers that get pushed onto it when a thread swap occurs, what else uses the thread stack? Unlike larger processors, where local variables goes onto the stack, with the AVR they go into .bss and .data, right? Thanks, Francois From dferbas at dfsoft.cz Tue Feb 24 15:42:03 2004 From: dferbas at dfsoft.cz (Dusan Ferbas) Date: Tue, 24 Feb 2004 15:42:03 +0100 Subject: [En-Nut-Discussion] Http server - ethereal In-Reply-To: <20040224110004.1B2352F42A6@p15095813.pureserver.info> References: <20040224110004.1B2352F42A6@p15095813.pureserver.info> Message-ID: <6.0.1.1.2.20040224151421.01c92f80@pop3.servery.cz> Hi, I experienced something similar 4 months ago. I reported it as a lost FIN packets. I suggest to collect our observations with Nut's TCP. I am interested if this appears to happen also with SMC chip on Ethernut 2 boards ? And what are memory and sockets configuration of your applications - how many threads, amount of available heap, how many http threads, which options are set, how many files needed for your web page, etc. Detailed comment follows: ---- If you do not know stream length at the beginning then Content-Length is missing in http header. Web browser waits for connection close to assume file was fully sent. If FIN is lost then it waits (IE and Mozilla 1.5 tested) forever. This never happens if there is a need only for 1 concurrent http connection. We have 1 html and 2 small picture files (667 and 884 bytes). Sometimes it happens that both pictures are not loaded. Then we have a .swf file (30kB) and 2 .xml files. With .swf we are sending Content-Length and never experienced unsent file (hopefully Flash will not start otherwise). Sometimes it happens that .xml (without Content-Length) are not loaded. Reloading by Ctrl-R (Mozilla) or Reload button always helps. We know Nut is not restarted even due to watch dog reset. This behaviour got better after Oliver Schulz contributed his timing changes in TCP. Hope this helps a little and directs to some debugging effort. I think that this can happen according either to problems with packet transfer from RTL chip or because of some misusage or crossusage of event resources. > u_long ul; > ul = 3000; > NutTcpSetSockOpt (sock, SO_SNDTIMEO, &ul, sizeof(ul)); > > if (NutTcpSetSockOpt(sock, TCP_MAXSEG, &tcp_mss, sizeof(tcp_mss))) > LOG_MSG("%u. Cannot set MSS sock opt\n", id); > > if (NutTcpSetSockOpt(sock, SO_SNDBUF, &tcp_mss, sizeof(tcp_mss))) > LOG_MSG("%u. Cannot set output buffer sock opt\n", id); > > NutTcpAccept(sock, gBoardDatap->http_port); // Listen on http > port (default:80). If we return, we got a client. >Date: Tue, 24 Feb 2004 16:05:36 +0800 >From: "Damian Slee" >Subject: RE: [En-Nut-Discussion] Http server - ethereal >To: "Ethernut User Chat (English)" > > >I have been looking at this in more detail today, cause I have had the >same problem as Cosmin since I started using ethernut 6+months ago. > >Running latest CVS, and new realtek driver. I had this problem before >the new realtek driver. > >I have a frames page with 3 sections in it, so 3 html files + frame >setup html file. Only text content + forms on the pages. > >The problem is that the main frame with a form on it sits there trying >to load for about 20 seconds, then it loads. I have traced this with >Ethereal. If I click on one of my menu links in the left frame, forcing >browser to open new connection, the form loads imediately. > >Originally I though this was cause I was only running 2 http threads, >but changing this to 4 or 8 makes no difference. Like Cosmin indicated >last week. > >... > >Any ideas on how to move forward on this? Dusan Ferbas www.dfsoft.cz From francois at asnone.com Tue Feb 24 16:59:47 2004 From: francois at asnone.com (Francois Rademeyer) Date: Tue, 24 Feb 2004 17:59:47 +0200 Subject: [En-Nut-Discussion] Thread stack References: <06e901c3fad8$4b341410$1b00a8c0@sonyfrademeyer> Message-ID: <06fd01c3faef$3a92e8e0$1b00a8c0@sonyfrademeyer> Ignore the message, I have figured it out by now. ----- Original Message ----- From: "Francois Rademeyer" To: "Ethernut User Chat (English)" Sent: Tuesday, February 24, 2004 3:15 PM Subject: [En-Nut-Discussion] Thread stack > Hi everyone, > > I have some stupid questions: > > Lately I have become very confused with all the GCC, AVR & NUT memories. I > am trying to find a good balance for the stack size specified when creating > threads. Except for all the registers that get pushed onto it when a thread > swap occurs, what else uses the thread stack? Unlike larger processors, > where local variables goes onto the stack, with the AVR they go into .bss > and .data, right? > > Thanks, > Francois > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From Gila at home.nl Tue Feb 24 21:37:27 2004 From: Gila at home.nl (Gila) Date: Tue, 24 Feb 2004 20:37:27 +0000 Subject: [En-Nut-Discussion] Thread stack In-Reply-To: <06fd01c3faef$3a92e8e0$1b00a8c0@sonyfrademeyer> References: <06e901c3fad8$4b341410$1b00a8c0@sonyfrademeyer> <06fd01c3faef$3a92e8e0$1b00a8c0@sonyfrademeyer> Message-ID: <1077655047.3501.0.camel@Gila> On Tue, 2004-02-24 at 15:59, Francois Rademeyer wrote: > Ignore the message, I have figured it out by now. Mind sharing it ? :) > ----- Original Message ----- > From: "Francois Rademeyer" > To: "Ethernut User Chat (English)" > Sent: Tuesday, February 24, 2004 3:15 PM > Subject: [En-Nut-Discussion] Thread stack > > > > Hi everyone, > > > > I have some stupid questions: > > > > Lately I have become very confused with all the GCC, AVR & NUT memories. > I > > am trying to find a good balance for the stack size specified when > creating > > threads. Except for all the registers that get pushed onto it when a > thread > > swap occurs, what else uses the thread stack? Unlike larger processors, > > where local variables goes onto the stack, with the AVR they go into .bss > > and .data, right? > > > > Thanks, > > Francois > > > > > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From damian at commtech.com.au Wed Feb 25 03:04:59 2004 From: damian at commtech.com.au (Damian Slee) Date: Wed, 25 Feb 2004 10:04:59 +0800 Subject: [En-Nut-Discussion] Http server - ethereal Message-ID: Originally 3 threads(1socket, 1uart, 1watchdog) + idle thread + 2 http threads Tried yesterday 3 threads + idle thread + 8 http threads Tried yesterday NUTDEBUG 2 threads + idle thread + 8 http threads. Problem disappeared. Tried yesterday 2 threads + idle thread + 8 http threads. Problem re-appears Content-Length sent with the 4 html files loaded. 1 index + 3 frame html files. They are all crurom generated. Always the last one gets stuck. Tried the old NIC driver again this morning, still the same. Ethernut does seem to go very quiet for that Syn retry 6 second period, like its either not receiving anything, or trying to respond, and its not being sent. Which of these, I'll try find out today. -----Original Message----- From: Dusan Ferbas [mailto:dferbas at dfsoft.cz] Sent: Tuesday, 24 February 2004 10:42 PM To: en-nut-discussion at egnite.de Subject: Re: RE: [En-Nut-Discussion] Http server - ethereal Hi, I experienced something similar 4 months ago. I reported it as a lost FIN packets. I suggest to collect our observations with Nut's TCP. I am interested if this appears to happen also with SMC chip on Ethernut 2 boards ? And what are memory and sockets configuration of your applications - how many threads, amount of available heap, how many http threads, which options are set, how many files needed for your web page, etc. Detailed comment follows: ---- If you do not know stream length at the beginning then Content-Length is missing in http header. Web browser waits for connection close to assume file was fully sent. If FIN is lost then it waits (IE and Mozilla 1.5 tested) forever. This never happens if there is a need only for 1 concurrent http connection. We have 1 html and 2 small picture files (667 and 884 bytes). Sometimes it happens that both pictures are not loaded. Then we have a .swf file (30kB) and 2 .xml files. With .swf we are sending Content-Length and never experienced unsent file (hopefully Flash will not start otherwise). Sometimes it happens that .xml (without Content-Length) are not loaded. Reloading by Ctrl-R (Mozilla) or Reload button always helps. We know Nut is not restarted even due to watch dog reset. This behaviour got better after Oliver Schulz contributed his timing changes in TCP. Hope this helps a little and directs to some debugging effort. I think that this can happen according either to problems with packet transfer from RTL chip or because of some misusage or crossusage of event resources. > u_long ul; > ul = 3000; > NutTcpSetSockOpt (sock, SO_SNDTIMEO, &ul, sizeof(ul)); > > if (NutTcpSetSockOpt(sock, TCP_MAXSEG, &tcp_mss, sizeof(tcp_mss))) > LOG_MSG("%u. Cannot set MSS sock opt\n", id); > > if (NutTcpSetSockOpt(sock, SO_SNDBUF, &tcp_mss, sizeof(tcp_mss))) > LOG_MSG("%u. Cannot set output buffer sock opt\n", > id); > > NutTcpAccept(sock, gBoardDatap->http_port); // Listen on http > port (default:80). If we return, we got a client. >Date: Tue, 24 Feb 2004 16:05:36 +0800 >From: "Damian Slee" >Subject: RE: [En-Nut-Discussion] Http server - ethereal >To: "Ethernut User Chat (English)" > > >I have been looking at this in more detail today, cause I have had the >same problem as Cosmin since I started using ethernut 6+months ago. > >Running latest CVS, and new realtek driver. I had this problem before >the new realtek driver. > >I have a frames page with 3 sections in it, so 3 html files + frame >setup html file. Only text content + forms on the pages. > >The problem is that the main frame with a form on it sits there trying >to load for about 20 seconds, then it loads. I have traced this with >Ethereal. If I click on one of my menu links in the left frame, >forcing browser to open new connection, the form loads imediately. > >Originally I though this was cause I was only running 2 http threads, >but changing this to 4 or 8 makes no difference. Like Cosmin indicated >last week. > >... > >Any ideas on how to move forward on this? Dusan Ferbas www.dfsoft.cz _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From francois at asnone.com Wed Feb 25 07:26:01 2004 From: francois at asnone.com (Francois Rademeyer) Date: Wed, 25 Feb 2004 08:26:01 +0200 Subject: [En-Nut-Discussion] Thread stack References: <06e901c3fad8$4b341410$1b00a8c0@sonyfrademeyer><06fd01c3faef$3a92e8e0$1b00a8c0@sonyfrademeyer> <1077655047.3501.0.camel@Gila> Message-ID: <071d01c3fb68$3d38f7a0$1b00a8c0@sonyfrademeyer> Read the following documents: http://www.ethernut.de/pdf/entet100.pdf & http://www.ethernut.de/pdf/enmem100.pdf They contain a very good explanation. Do determine the excess stack memory, place the following logging code in the deepest function calls with most local variables: #include printf_P(PSTR("Free thread stack: %u\n"), (u_short) runningThread->td_sp - (u_short) runningThread->td_memory); In one of my projects I don't have external RAM due to shortage of pins (not even a single one!) and the use of a large graphic LCD. I have 4 threads and use 1 uart driver. With Nut-Os you really have to economise. I have stacks of SPI flash memory available (16Mbits) and if things get any tighter, I'm thinking about writing a mod that swaps the thread stack to flash. Now when will Atmel bring out an ATmega256 with 64K internal RAM? Probably never. When will someone have a port of Nut-Os ready for the ARM? GCC already has an ARM port, but the cost of developing for the ARM is very high. Yoda would have said: "Stuck between a rock and a hard place, I am.". Cheers, Francois ----- Original Message ----- From: "Gila" To: "Ethernut User Chat (English)" Sent: Tuesday, February 24, 2004 10:37 PM Subject: Re: [En-Nut-Discussion] Thread stack > On Tue, 2004-02-24 at 15:59, Francois Rademeyer wrote: > > Ignore the message, I have figured it out by now. > > Mind sharing it ? :) > > > > ----- Original Message ----- > > From: "Francois Rademeyer" > > To: "Ethernut User Chat (English)" > > Sent: Tuesday, February 24, 2004 3:15 PM > > Subject: [En-Nut-Discussion] Thread stack > > > > > > > Hi everyone, > > > > > > I have some stupid questions: > > > > > > Lately I have become very confused with all the GCC, AVR & NUT memories. > > I > > > am trying to find a good balance for the stack size specified when > > creating > > > threads. Except for all the registers that get pushed onto it when a > > thread > > > swap occurs, what else uses the thread stack? Unlike larger processors, > > > where local variables goes onto the stack, with the AVR they go into .bss > > > and .data, right? > > > > > > Thanks, > > > Francois > > > > > > > > > _______________________________________________ > > > En-Nut-Discussion mailing list > > > En-Nut-Discussion at egnite.de > > > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > > > > > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From damian at commtech.com.au Wed Feb 25 07:44:29 2004 From: damian at commtech.com.au (Damian Slee) Date: Wed, 25 Feb 2004 14:44:29 +0800 Subject: [En-Nut-Discussion] Http server - TCP state machine fix Message-ID: Hi all, Further to my email yesterday regarding occasionally SYN ACK not being received, I have traced that; - every SYN sent by the PC is received by ethernut - every SYN received in listening state has a SYN ACK generated. - NutIpOutput does Not fail in NutTcpOutput. So it should be passed all the way down to NicOutput() So it must be lost somewhere between NicOutput and received by the PC. This would be similar to the lost FIN of Dusan Ferbas findings. I put my money on it being lost by NicOutput/Realtek somewhere. -------------------- Moving on. I found that in tcpsm.c; - after a SYN is received, SYN ACK sent, switch to SYN RECEIVED state. Ok - SYN ACK disappears. Not so ok. - PC sends another SYN, after timeout of 3 and 6 seconds. Ok - Ethernut receives these SYNs in SYN RECEIVED STATE. ** the problem in NutTcpStateSynReceived() ** - this "without ACK" check is done before the Reject SYNs check. Therefore the Reject SYNs code will Never execute, cause the first handshake SYN from the PC doesn't have an ACK. Needs to be Swapped around. Result, a RST is sent imediately back to the PC, re-sync, page loads immediately. Should the same change apply to NutTcpStateFinWait1(), NutTcpStateFinWait2(), NutTcpStateCloseWait(), NutTcpStateClosing(), and NutTcpStateLastAck() ?? /* * Silently discard segments without ACK. */ if ((flags & TH_ACK) == 0) { NutNetBufFree(nb); return; } ... /* * Reject SYNs. */ if (flags & TH_SYN) { /* this code never executes, because of return above */ NutTcpReject(nb); return; } damian From damian at commtech.com.au Wed Feb 25 08:39:45 2004 From: damian at commtech.com.au (Damian Slee) Date: Wed, 25 Feb 2004 15:39:45 +0800 Subject: [En-Nut-Discussion] Http server - TCP state machine fix Message-ID: NicPutPacket() is definitely writing out the SYN ACK packet that is lost, so must be realtek or LAN loosing it. Will try crossover LAN cable tomorrow, ethernut direct to PC NIC. Eliminate any network switches etc... -----Original Message----- From: Damian Slee Sent: Wednesday, 25 February 2004 2:44 PM To: Ethernut User Chat (English) Subject: RE: [En-Nut-Discussion] Http server - TCP state machine fix Hi all, Further to my email yesterday regarding occasionally SYN ACK not being received, I have traced that; - every SYN sent by the PC is received by ethernut - every SYN received in listening state has a SYN ACK generated. - NutIpOutput does Not fail in NutTcpOutput. So it should be passed all the way down to NicOutput() So it must be lost somewhere between NicOutput and received by the PC. This would be similar to the lost FIN of Dusan Ferbas findings. I put my money on it being lost by NicOutput/Realtek somewhere. -------------------- Moving on. I found that in tcpsm.c; - after a SYN is received, SYN ACK sent, switch to SYN RECEIVED state. Ok - SYN ACK disappears. Not so ok. - PC sends another SYN, after timeout of 3 and 6 seconds. Ok - Ethernut receives these SYNs in SYN RECEIVED STATE. ** the problem in NutTcpStateSynReceived() ** - this "without ACK" check is done before the Reject SYNs check. Therefore the Reject SYNs code will Never execute, cause the first handshake SYN from the PC doesn't have an ACK. Needs to be Swapped around. Result, a RST is sent imediately back to the PC, re-sync, page loads immediately. Should the same change apply to NutTcpStateFinWait1(), NutTcpStateFinWait2(), NutTcpStateCloseWait(), NutTcpStateClosing(), and NutTcpStateLastAck() ?? /* * Silently discard segments without ACK. */ if ((flags & TH_ACK) == 0) { NutNetBufFree(nb); return; } ... /* * Reject SYNs. */ if (flags & TH_SYN) { /* this code never executes, because of return above */ NutTcpReject(nb); return; } damian _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From Oliver.Schulz at bong.de Wed Feb 25 08:40:05 2004 From: Oliver.Schulz at bong.de (Oliver Schulz) Date: Wed, 25 Feb 2004 08:40:05 +0100 Subject: AW: [En-Nut-Discussion] Thread stack Message-ID: Hi, also look here: http://www.egnite.de/pipermail/en-nut-discussion/2004-January/001769.html This separate interrupt stack will be included in Nut/OS 3.5 for avr-gcc only. It's already in the HEAD branch for testing. Cheers, Oliver. > -----Urspr?ngliche Nachricht----- > Von: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Francois > Rademeyer > Gesendet: Dienstag, 24. Februar 2004 14:16 > An: Ethernut User Chat (English) > Betreff: [En-Nut-Discussion] Thread stack > > > Hi everyone, > > I have some stupid questions: > > Lately I have become very confused with all the GCC, AVR & > NUT memories. I > am trying to find a good balance for the stack size specified > when creating > threads. Except for all the registers that get pushed onto > it when a thread > swap occurs, what else uses the thread stack? Unlike larger > processors, > where local variables goes onto the stack, with the AVR they > go into .bss > and .data, right? > > Thanks, > Francois > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From Oliver.Schulz at bong.de Wed Feb 25 08:47:55 2004 From: Oliver.Schulz at bong.de (Oliver Schulz) Date: Wed, 25 Feb 2004 08:47:55 +0100 Subject: AW: [En-Nut-Discussion] Http server - TCP state machine fix Message-ID: Hi Damian, some days ago, I tried to figure out why NutConnect sometimes get stucked. The reason was that the whole software stuff, including the realtek driver, reported success for sending the initial SYN TCP packet, but this packet was definitely not put on the LAN. My bugfix was, to use the retransmission timer for NutConnect, because the next packet was then transmitted correctly. But I didn't this testing again with the new driver from Bengan. While testing, I noticed a strange behaviour: If you put a 'NutDelay(1)' somewhere in NicPutPacket, everything seems to be ok then (except the performance, of course :-).... So long, Oliver. > -----Urspr?ngliche Nachricht----- > Von: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Damian Slee > Gesendet: Mittwoch, 25. Februar 2004 08:40 > An: Ethernut User Chat (English) > Betreff: RE: [En-Nut-Discussion] Http server - TCP state machine fix > > > NicPutPacket() is definitely writing out the SYN ACK packet that is > lost, so must be realtek or LAN loosing it. Will try crossover LAN > cable tomorrow, ethernut direct to PC NIC. Eliminate any network > switches etc... > > > -----Original Message----- > From: Damian Slee > Sent: Wednesday, 25 February 2004 2:44 PM > To: Ethernut User Chat (English) > Subject: RE: [En-Nut-Discussion] Http server - TCP state machine fix > > Hi all, > Further to my email yesterday regarding occasionally SYN ACK not being > received, I have traced that; > > - every SYN sent by the PC is received by ethernut > > - every SYN received in listening state has a SYN ACK generated. > > - NutIpOutput does Not fail in NutTcpOutput. So it should be > passed all > the way down to NicOutput() > > So it must be lost somewhere between NicOutput and received by the PC. > This would be similar to the lost FIN of Dusan Ferbas findings. I put > my money on it being lost by NicOutput/Realtek somewhere. > > -------------------- > Moving on. I found that in tcpsm.c; > - after a SYN is received, SYN ACK sent, switch to SYN RECEIVED state. > Ok > > - SYN ACK disappears. Not so ok. > > - PC sends another SYN, after timeout of 3 and 6 seconds. Ok > > - Ethernut receives these SYNs in SYN RECEIVED STATE. > > ** the problem in NutTcpStateSynReceived() ** > > - this "without ACK" check is done before the Reject SYNs check. > Therefore the Reject SYNs code will Never execute, cause the first > handshake SYN from the PC doesn't have an ACK. Needs to be Swapped > around. Result, a RST is sent imediately back to the PC, > re-sync, page > loads immediately. > > Should the same change apply to NutTcpStateFinWait1(), > NutTcpStateFinWait2(), NutTcpStateCloseWait(), > NutTcpStateClosing(), and > NutTcpStateLastAck() ?? > > > /* > * Silently discard segments without ACK. > */ > if ((flags & TH_ACK) == 0) { > NutNetBufFree(nb); > return; > } > ... > /* > * Reject SYNs. > */ > if (flags & TH_SYN) { > /* this code never executes, because of return above */ > NutTcpReject(nb); > return; > } > > > > damian > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From damian at commtech.com.au Wed Feb 25 09:14:19 2004 From: damian at commtech.com.au (Damian Slee) Date: Wed, 25 Feb 2004 16:14:19 +0800 Subject: [En-Nut-Discussion] Http server - TCP state machine fix Message-ID: Hi Oliver, I'm using the new driver with this problem. Tho I think it occurs in the old as well. Maybe there is another busy bit check or something needed. Do you agree with my NutTcpStateSynReceived() fix? Anyone, How does a call to NutTcpReject(), return it to a listening state? If there a FIN or something sent from the other end when they receive the RST? Thanks, damian -----Original Message----- From: Oliver Schulz [mailto:Oliver.Schulz at bong.de] Sent: Wednesday, 25 February 2004 3:48 PM To: Ethernut User Chat (English) Subject: AW: [En-Nut-Discussion] Http server - TCP state machine fix Hi Damian, some days ago, I tried to figure out why NutConnect sometimes get stucked. The reason was that the whole software stuff, including the realtek driver, reported success for sending the initial SYN TCP packet, but this packet was definitely not put on the LAN. My bugfix was, to use the retransmission timer for NutConnect, because the next packet was then transmitted correctly. But I didn't this testing again with the new driver from Bengan. While testing, I noticed a strange behaviour: If you put a 'NutDelay(1)' somewhere in NicPutPacket, everything seems to be ok then (except the performance, of course :-).... So long, Oliver. > -----Urspr?ngliche Nachricht----- > Von: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Damian Slee > Gesendet: Mittwoch, 25. Februar 2004 08:40 > An: Ethernut User Chat (English) > Betreff: RE: [En-Nut-Discussion] Http server - TCP state machine fix > > > NicPutPacket() is definitely writing out the SYN ACK packet that is > lost, so must be realtek or LAN loosing it. Will try crossover LAN > cable tomorrow, ethernut direct to PC NIC. Eliminate any network > switches etc... > > > -----Original Message----- > From: Damian Slee > Sent: Wednesday, 25 February 2004 2:44 PM > To: Ethernut User Chat (English) > Subject: RE: [En-Nut-Discussion] Http server - TCP state machine fix > > Hi all, > Further to my email yesterday regarding occasionally SYN ACK not being > received, I have traced that; > > - every SYN sent by the PC is received by ethernut > > - every SYN received in listening state has a SYN ACK generated. > > - NutIpOutput does Not fail in NutTcpOutput. So it should be passed > all the way down to NicOutput() > > So it must be lost somewhere between NicOutput and received by the PC. > This would be similar to the lost FIN of Dusan Ferbas findings. I put > my money on it being lost by NicOutput/Realtek somewhere. > > -------------------- > Moving on. I found that in tcpsm.c; > - after a SYN is received, SYN ACK sent, switch to SYN RECEIVED state. > Ok > > - SYN ACK disappears. Not so ok. > > - PC sends another SYN, after timeout of 3 and 6 seconds. Ok > > - Ethernut receives these SYNs in SYN RECEIVED STATE. > > ** the problem in NutTcpStateSynReceived() ** > > - this "without ACK" check is done before the Reject SYNs check. > Therefore the Reject SYNs code will Never execute, cause the first > handshake SYN from the PC doesn't have an ACK. Needs to be Swapped > around. Result, a RST is sent imediately back to the PC, re-sync, > page loads immediately. > > Should the same change apply to NutTcpStateFinWait1(), > NutTcpStateFinWait2(), NutTcpStateCloseWait(), NutTcpStateClosing(), > and > NutTcpStateLastAck() ?? > > > /* > * Silently discard segments without ACK. > */ > if ((flags & TH_ACK) == 0) { > NutNetBufFree(nb); > return; > } > ... > /* > * Reject SYNs. > */ > if (flags & TH_SYN) { > /* this code never executes, because of return above */ > NutTcpReject(nb); > return; > } > > > > damian > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From francois at asnone.com Wed Feb 25 13:33:34 2004 From: francois at asnone.com (Francois Rademeyer) Date: Wed, 25 Feb 2004 14:33:34 +0200 Subject: [En-Nut-Discussion] sscanf_P bug Message-ID: <079d01c3fb9b$95e82eb0$1b00a8c0@sonyfrademeyer> Just a bug I noticed: int sscanf_P(CONST char *string, CONST char *fmt, ...) should be int sscanf_P(CONST char *string, PGM_P fmt, ...) From francois at asnone.com Wed Feb 25 16:31:02 2004 From: francois at asnone.com (Francois Rademeyer) Date: Wed, 25 Feb 2004 17:31:02 +0200 Subject: [En-Nut-Discussion] Fw: scanf is very buggy! Message-ID: <07f301c3fbb4$6272c680$1b00a8c0@sonyfrademeyer> Attached is a new version for _getf that fixes two scanf bugs: 1) %% causes errors. 2) When an integer is parsed, the for loop steps 1 char too far at the end, which gives problems with subsequent parsing. 3) %u was not supported. Does anybody use scanf? -------------- next part -------------- A non-text attachment was scrubbed... Name: getf.zip Type: application/octet-stream Size: 3310 bytes Desc: not available Url : http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040225/78ecfeae/attachment.obj From lightfreakde at yahoo.com Wed Feb 25 17:21:18 2004 From: lightfreakde at yahoo.com (Simon Biniek) Date: Wed, 25 Feb 2004 08:21:18 -0800 (PST) Subject: [En-Nut-Discussion] Fw: scanf is very buggy! In-Reply-To: <07f301c3fbb4$6272c680$1b00a8c0@sonyfrademeyer> Message-ID: <20040225162118.86954.qmail@web13501.mail.yahoo.com> Hi, it is kwon, that scanf in general is not that good as expected. E.g. in Borlandc++ 3.1 the scanf function caused a program hang when you scan for an integer and typed in characters. Simon __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools From harald.kipp at egnite.de Wed Feb 25 17:56:29 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 25 Feb 2004 17:56:29 +0100 Subject: [En-Nut-Discussion] Fw: scanf is very buggy! In-Reply-To: <07f301c3fbb4$6272c680$1b00a8c0@sonyfrademeyer> Message-ID: <5.1.1.6.0.20040225175028.032e21e0@egnite.de> I guess, Oliver will take care of this. Possible reason for all these bugs: I never liked scanf, but agree, that it's very powerful when reading files. Many thanks. I just committed several changes to HEAD: * dev/debug*.c: Added ioctl baudrate support. * dev/lanc111.c, net/ifconfig.c: Avoid chip initialization with MAC address zero. This is a quick hack for all this init mess. * include/pro/dhcp.h: Added NutDhcpRelease prototype. * pro/dhcpc.c: New API added to relinguish the DHCP lease. Collecting more than one offer is now disabled, if the application sets timeout below three times of MAX_DHCP_WAIT (5 seconds). The lease renewal will now start when 3/4 has elapsed, opposed to 1/2 used previously. Finally the DHCP thread will sleep as long as possible, while the previous version woke up every ten seconds. DHCP is now kind of snappier. Harald At 17:31 25.02.2004 +0200, you wrote: > Attached is a new version for _getf that fixes two scanf bugs: > > 1) %% causes errors. >2) When an integer is parsed, the for loop steps 1 char too far at the end, >which gives problems with subsequent parsing. >3) %u was not supported. > > Does anybody use scanf? > From olischulz at web.de Wed Feb 25 20:22:33 2004 From: olischulz at web.de (Oliver Schulz) Date: Wed, 25 Feb 2004 20:22:33 +0100 Subject: AW: [En-Nut-Discussion] Fw: scanf is very buggy! In-Reply-To: <5.1.1.6.0.20040225175028.032e21e0@egnite.de> Message-ID: <000901c3fbd4$b8c36ec0$5b42a8c0@ose.de> Hi! > I guess, Oliver will take care of this. I will do as soon as I can. > Possible reason for all these bugs: I never liked > scanf, but agree, that it's very powerful when reading Yes, I didn't use it very often, but never so far in Nut/OS... Strange, that nobody noticed it before .-) > > > > Does anybody use scanf? > > ... that's the question ;-) Cheers, Oliver. From fischermi at t-online.de Wed Feb 25 21:25:29 2004 From: fischermi at t-online.de (Michael Fischer) Date: Wed, 25 Feb 2004 21:25:29 +0100 Subject: [En-Nut-Discussion] Ethernut 2 AddressRange? Message-ID: Hello, does anybody know if the address range from 0xFFF0 to 0xFFFF is free for an IO card on Ethernut2? Regards, Michael From olischulz at web.de Wed Feb 25 23:51:41 2004 From: olischulz at web.de (Oliver Schulz) Date: Wed, 25 Feb 2004 23:51:41 +0100 Subject: AW: [En-Nut-Discussion] Http server - TCP state machine fix In-Reply-To: Message-ID: <000001c3fbf1$f00a41c0$5b42a8c0@ose.de> Hi Damian, regarding your found bug in NutTcpStateSynReceived (and perhaps in NutTcpStateFinWait1(), NutTcpStateFinWait2(), NutTcpStateCloseWait(), NutTcpStateClosing() and NutTcpStateLastAck()), I have to take some time to look again at these big tcp state machine to be sure not to add some more side effects... But on the first look, I would say you're right. So long, Oliver. > -----Urspr?ngliche Nachricht----- > Von: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Damian Slee > Gesendet: Mittwoch, 25. Februar 2004 09:14 > An: Ethernut User Chat (English) > Betreff: RE: [En-Nut-Discussion] Http server - TCP state machine fix > > > Hi Oliver, > I'm using the new driver with this problem. Tho I think it > occurs in the old as well. > Maybe there is another busy bit check or something needed. > > Do you agree with my NutTcpStateSynReceived() fix? > > Anyone, > How does a call to NutTcpReject(), return it to a listening state? > If there a FIN or something sent from the other end when they > receive the RST? > > Thanks, > > damian > > -----Original Message----- > From: Oliver Schulz [mailto:Oliver.Schulz at bong.de] > Sent: Wednesday, 25 February 2004 3:48 PM > To: Ethernut User Chat (English) > Subject: AW: [En-Nut-Discussion] Http server - TCP state machine fix > > Hi Damian, > > some days ago, I tried to figure out why NutConnect sometimes > get stucked. > The reason was that the whole software stuff, including the > realtek driver, reported success for sending the initial SYN > TCP packet, but this packet was definitely not put on the LAN. > > My bugfix was, to use the retransmission timer for > NutConnect, because the next packet was then transmitted correctly. > But I didn't this testing again with the new driver from Bengan. > > While testing, I noticed a strange behaviour: If you put a > 'NutDelay(1)' somewhere in NicPutPacket, everything seems to > be ok then (except the performance, of course :-).... > > So long, > Oliver. > [snip] -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2852 bytes Desc: not available Url : http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040225/230fa018/attachment.bin From damian at commtech.com.au Thu Feb 26 10:44:45 2004 From: damian at commtech.com.au (Damian Slee) Date: Thu, 26 Feb 2004 17:44:45 +0800 Subject: [En-Nut-Discussion] Realtek driver fix for Tx packet loss Message-ID: Will give more details on the fix tommorrow after some more testing. Here are my findings after lots of debuging and tracing today; - I haven't applied the TCP SM fix from yesterday, so I could use the browser page load fail as a visual indication of the SYN ACK packet being dropped on Tx from realtek. I eventually found that when ever I had a html page fail to load, that an NicInterrupt() was being generated with interrupt status register (ISR) bit NIC_ISR_RXE (receive error bit) being set. This corresponded very very closely to the point in time where the SYN ACK was failing to be transmitted. I was also getting the ISR receive error bit set at some other times. These turned out later to be at the same time other packets where being dropped. Some FIN packets, and data packets. Traced the cause of the receive error through the receive status register to be DFR bit (0x80) in receive status register. "Defferring. Set when a carrier or a collision is detected." Not sure why it still happens on a crossover LAN cable PC<->Ethernut. After a lot more tracing, I found that if I read the receive status register straight after "Start transmission", the times it failed the DFR bit was set. Further to this, the transmit start bit TXP in command register, gets reset back to 0, indicating "transmission is completed or aborted". I tried checking TXP bit on its own, but it seems I had to read the receive status register first? Either that or it needs a nop or two before checking TXP after a start transmission(tomorrow). I have implemented a retry, which when detecting the above, simply does a start transmission again, do..while(failed) kinda thing. Occasionally it has retried twice. I have tested this to the point where I get some debug output (RS232) when the retries occur, and capturing with etherreal. Where the retries occur, I am inspecting ethereal for duplicate or missing packets. Seems to be No duplicates, and No missing packets. More tomorrow, damn I'm hungry cause I missed lunch. From chromy at asix.cz Fri Feb 27 09:34:58 2004 From: chromy at asix.cz (Pavel Chromy) Date: Fri, 27 Feb 2004 09:34:58 +0100 Subject: [En-Nut-Discussion] fflush on input Message-ID: <403F0132.8040904@asix.cz> > I use fflush to ensure the output goes to destination but I wouldnt want > to lose incoming data already queued just because the output thread > wanted to hurry up.... How should I be forcing output buffer to flush > without affecting incoming stream data? > Message: 4 > Date: Thu, 11 Dec 2003 15:08:28 +0100 > From: Harald Kipp > Subject: Re: [En-Nut-Discussion] fflush newbie question > To: togrady at comtech.uk.com, "Ethernut User Chat (English)" > > Message-ID: <5.1.1.6.0.20031211150609.02d48d18 at egnite.de> > Content-Type: text/plain; charset="us-ascii"; format=flowed > > fflush forces data output only. It does not flush the input > buffer, which is considered an error and will be changed. > > fflush shall force output and discard the input. I bit outdated reply: I think this that discarding output in fflush is a bad idea as Brett pointed out. There might be a separate function discarding input, which is usually called purge (probably fpurge?). Pavel From eeaj2002 at yahoo.com Thu Feb 26 19:52:29 2004 From: eeaj2002 at yahoo.com (john Mcdonald) Date: Thu, 26 Feb 2004 10:52:29 -0800 (PST) Subject: [En-Nut-Discussion] Optrex F-51553 LCD display Message-ID: <20040226185229.20543.qmail@web14807.mail.yahoo.com> This message is for Michael G. Svob, Hi Micheal, Can I have a copy of the code you wrote for F-51553 optrex display please. Thanks, John. --------------------------------- Do you Yahoo!? Get better spam protection with Yahoo! Mail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040226/7535a320/attachment.html From Oliver.Schulz at bong.de Fri Feb 27 10:04:33 2004 From: Oliver.Schulz at bong.de (Oliver Schulz) Date: Fri, 27 Feb 2004 10:04:33 +0100 Subject: AW: [En-Nut-Discussion] fflush on input Message-ID: Hi, to finally clearify this fflush issue: By calling 'fflush', the device's write function is called with parameter 'len' set to zero. It's up to the device driver to handle this special write. The USART device driver and TCPSOCKET virtual device will then sent any buffered output data to the device output function. That means output buffers are flushed, but NOT discarded. The input buffer is NOT touched in any manner, means that it is also NOT discarded. Actually there is no function to discard input buffers, but IMHO it would be nice to have one. I will look how to implement 'fpurge' this weekend (and commitin' some other queued bugfixes to CVS). Regards, Oliver. > -----Urspr?ngliche Nachricht----- > Von: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von > Pavel Chromy > Gesendet: Freitag, 27. Februar 2004 09:35 > An: Ethernut User Chat (English) > Betreff: Re: [En-Nut-Discussion] fflush on input > > > > > I use fflush to ensure the output goes to destination but I > wouldnt want > > to lose incoming data already queued just because the output thread > > wanted to hurry up.... How should I be forcing output > buffer to flush > > without affecting incoming stream data? > > > Message: 4 > > Date: Thu, 11 Dec 2003 15:08:28 +0100 > > From: Harald Kipp > > Subject: Re: [En-Nut-Discussion] fflush newbie question > > To: togrady at comtech.uk.com, "Ethernut User Chat (English)" > > > > Message-ID: <5.1.1.6.0.20031211150609.02d48d18 at egnite.de> > > Content-Type: text/plain; charset="us-ascii"; format=flowed > > > > fflush forces data output only. It does not flush the input > > buffer, which is considered an error and will be changed. > > > > fflush shall force output and discard the input. > > I bit outdated reply: > I think this that discarding output in fflush is a bad idea > as Brett pointed out. > There might be a separate function discarding input, which is > usually called > purge (probably fpurge?). > > Pavel > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From damian at commtech.com.au Fri Feb 27 10:31:12 2004 From: damian at commtech.com.au (Damian Slee) Date: Fri, 27 Feb 2004 17:31:12 +0800 Subject: [En-Nut-Discussion] My latest usartavr.c Message-ID: - When selecting software flow control, XON will be sent on next read, if low water mark is reached. - when XOFF received, transmitter now stops. - #define UART_HDX_FLIP_BIT to invert the polarity of the half duplex pin. This makes it the same polarity as RTS Toggle done by the Windows NT comms driver. damian -------------- next part -------------- A non-text attachment was scrubbed... Name: usartavr.zip Type: application/x-zip-compressed Size: 6644 bytes Desc: usartavr.zip Url : http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040227/c077f5c3/attachment.bin From gedas at tvk.lt Fri Feb 27 10:35:37 2004 From: gedas at tvk.lt (Gediminas Simanskis) Date: Fri, 27 Feb 2004 11:35:37 +0200 Subject: [En-Nut-Discussion] Netgear wireless 802.11b PCMCIA card References: Message-ID: <000501c3fd15$0eaff920$0a00000a@p350> Does anybody have intersil PRISM Driver Programmer's Manual ? From ceba at vabo.cz Fri Feb 27 11:40:07 2004 From: ceba at vabo.cz (Pavel Celeda) Date: Fri, 27 Feb 2004 11:40:07 +0100 Subject: [En-Nut-Discussion] Ethernut network configuration bug Message-ID: <1077878406.2417.47.camel@hw.vabo.cz> This week I have discovered racecondition during setting up eth0 network configuration. This bug affects both static eeprom and dhcp configuration. Nut/OS version 3.4.1.1 - CVS snapshot Initial situation: Ethernut I. board with static eeprom configuration. Device is UP and runnig on the local network. PC1(Linux) ----> router ----> Ethernut I. (IP1) ping IP1, everything works fine. Ping is running continually. 1) static eeprom configuration I change Ethernut's IP addres (IP1->IP2) via serial terminal and save it to the eeprom - NutNetSaveConfig(). Now I press reset button and the Ethernut starts with IP1 instead with IP2. I use following procedure for configuring eth0 device. NutNetLoadConfig(); NutRegisterDevice(); ... configuration racecondition in NutIpInput() ... NutNetIfConfig(); NutIpRouteAdd(); ICMP datagrams are still comming from PC1. I have discovered that NutIpInput() contains code which calls NutNetIfSetup() and this piece of code kill my previous eeprom configuration (IP2->IP1 and discards rest of network configuration). I known "That's not a bug, that's a feature" used to setup IP address via dynamic IP ARP method. But I thing nowadays when we can use dhcp for setting up network configuration this feature should be by default disabled. 2) dhcp configuration The same configuration (PC1, router, Ethernut). Ethernut will get IP address from dhcp server (FreeBSD - ISC DHCPv3.0.1rc11) on the same local network segment. Now I start ping IP1 and press reset on Ethernut board. NetDhcpIfConfig fails and I can't obtain valid configuration from dhcp server. I patched the NutIpInput() and removed the code with NutNetIfSetup() and now everything works fine. with best regards Pavel From damian at commtech.com.au Fri Feb 27 12:18:23 2004 From: damian at commtech.com.au (Damian Slee) Date: Fri, 27 Feb 2004 19:18:23 +0800 Subject: [En-Nut-Discussion] My latest usartavr.c Message-ID: - and enables tx complete interrupt for half duplex mode, when you use SetFlowControl(). -----Original Message----- From: Damian Slee Sent: Fri 27/02/2004 5:31 PM To: Ethernut User Chat (English) Cc: Subject: [En-Nut-Discussion] My latest usartavr.c - When selecting software flow control, XON will be sent on next read, if low water mark is reached. - when XOFF received, transmitter now stops. - #define UART_HDX_FLIP_BIT to invert the polarity of the half duplex pin. This makes it the same polarity as RTS Toggle done by the Windows NT comms driver. damian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 4030 bytes Desc: not available Url : http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040227/4c5f8cd0/attachment.bin From harald.kipp at egnite.de Fri Feb 27 12:28:47 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Fri, 27 Feb 2004 12:28:47 +0100 Subject: [En-Nut-Discussion] Netgear wireless 802.11b PCMCIA card In-Reply-To: Message-ID: <5.1.1.6.0.20040227122145.01bd9508@egnite.de> Hi, I rejected a response from Jean Pierre, because 1. Large attachments will spoil our archive. 2. Not all subscribers are prepared to receive monster emails. 3. The distribution of this NDA protected document might be illegal (but I do not know for sure). Anyway, thanks for your help, Jean Pierre. Please pass the document directly to Gediminas Simanskis gedas at tvk dot lt Regards, Harald From harald.kipp at egnite.de Fri Feb 27 12:53:24 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Fri, 27 Feb 2004 12:53:24 +0100 Subject: [En-Nut-Discussion] Ethernut network configuration bug In-Reply-To: <1077878406.2417.47.camel@hw.vabo.cz> Message-ID: <5.1.1.6.0.20040227123431.032bfea8@egnite.de> Hi Pavel, I do not fully agree. I'm aware that this race condition exists, but I think you fixed it too easily. Two reasons: 1. Many Ethernut users still do not have DHCP. 2. The race condition appears only, if you ping a configured Ethernut, reset the Ethernut while pinging and trying to assign a new IP address. Otherwise the pinging host will send an ARP request first. Since the Ethernuts are equipped with ATmega128 chips with retain-EEPROM fuse, the situation is better, but we still have many users of ATMega103 Ethernuts. I may accept to limit the ARP method to ATmega103 systems. Simply removing it for the rare condition you described would leave others in the rain. And I need to update the docs (which needs to be done anyway, I know). Nevertheless, DHCP should not fail. This is indeed an issue. Regards, Harald From jesperh at telia.com Fri Feb 27 14:32:41 2004 From: jesperh at telia.com (Jesper Hansen) Date: Fri, 27 Feb 2004 14:32:41 +0100 Subject: [En-Nut-Discussion] Netgear wireless 802.11b PCMCIA card References: <5.1.1.6.0.20040227122145.01bd9508@egnite.de> Message-ID: <01af01c3fd36$32ce7b80$6500a8c0@jeha> I can't help breaking in here, and say that, as I'm working on 802.11 support too, I would VERY much appreciate a copy of this document too, Jean Pierre !! /Jesper ----- Original Message ----- From: "Harald Kipp" To: Sent: Friday, February 27, 2004 12:28 PM Subject: [En-Nut-Discussion] Netgear wireless 802.11b PCMCIA card > Hi, > > I rejected a response from Jean Pierre, because > > 1. Large attachments will spoil our archive. > 2. Not all subscribers are prepared to receive monster emails. > 3. The distribution of this NDA protected document might be > illegal (but I do not know for sure). > > Anyway, thanks for your help, Jean Pierre. Please pass the > document directly to Gediminas Simanskis gedas at tvk dot lt > > Regards, > > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From zodianet at wanadoo.fr Fri Feb 27 14:37:29 2004 From: zodianet at wanadoo.fr (Zodianet) Date: Fri, 27 Feb 2004 14:37:29 +0100 Subject: [En-Nut-Discussion] NutDnsGetHostByName bug ? In-Reply-To: <5.1.1.6.0.20040227123431.032bfea8@egnite.de> Message-ID: <20040227133941.9D6FB18001AD@mwinf0801.wanadoo.fr> NutDnsGetHostByName (resolv.c) seems to not release correctly memory alloc, "doq->doq_name" in CreateDnsQuestion function. A single but not very elegant test "if (doq->doq_name) NutHeapFree(doq->doq_name)" seems suppress this bug. Jean Pierre static DNSQUESTION *CreateDnsQuestion(DNSQUESTION * doq, CONST u_char * name) { if (doq == 0) doq = NutHeapAllocClear(sizeof(DNSQUESTION)); if (doq) { if (doq->doq_name) // <--------- NutHeapFree(doq->doq_name); // <---------- doq->doq_name = NutHeapAlloc(strlen(name) + 1); strcpy(doq->doq_name, name); doq->doq_type = 1; doq->doq_class = 1; } From zodianet at wanadoo.fr Fri Feb 27 17:07:47 2004 From: zodianet at wanadoo.fr (Zodianet) Date: Fri, 27 Feb 2004 17:07:47 +0100 Subject: [En-Nut-Discussion] RE: [En-Nut-Discussion ] Prism Manual link for anybody... In-Reply-To: <01af01c3fd36$32ce7b80$6500a8c0@jeha> Message-ID: <20040227160959.6FF111800055@mwinf0804.wanadoo.fr> http://home.kpnqwest.cz/jt/wifi/RM0251.pdf I think this link (found after 7'' with Google "RM0251 prim") is not under NDA ;-) I agree, it's too easy to find this document with its name :-) Jean Pierre -----Message d'origine----- De : en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de] De la part de Jesper Hansen Envoy? : vendredi 27 f?vrier 2004 14:33 ? : Ethernut User Chat (English) Objet : Re: [En-Nut-Discussion] Netgear wireless 802.11b PCMCIA card I can't help breaking in here, and say that, as I'm working on 802.11 support too, I would VERY much appreciate a copy of this document too, Jean Pierre !! /Jesper ----- Original Message ----- From: "Harald Kipp" To: Sent: Friday, February 27, 2004 12:28 PM Subject: [En-Nut-Discussion] Netgear wireless 802.11b PCMCIA card > Hi, > > I rejected a response from Jean Pierre, because > > 1. Large attachments will spoil our archive. > 2. Not all subscribers are prepared to receive monster emails. > 3. The distribution of this NDA protected document might be > illegal (but I do not know for sure). > > Anyway, thanks for your help, Jean Pierre. Please pass the > document directly to Gediminas Simanskis gedas at tvk dot lt > > Regards, > > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From harald.kipp at egnite.de Fri Feb 27 18:36:47 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Fri, 27 Feb 2004 18:36:47 +0100 Subject: [En-Nut-Discussion] RE: [En-Nut-Discussion ] Prism Manual link for anybody... In-Reply-To: <20040227160959.6FF111800055@mwinf0804.wanadoo.fr> References: <01af01c3fd36$32ce7b80$6500a8c0@jeha> Message-ID: <5.1.1.6.0.20040227182710.0335aec0@egnite.de> Jean Pierre, you wrote > I think this link (found after 7'' with Google "RM0251 prim") is not under > NDA ;-) The very first sentence clearly states: "For distribution under a Non-Disclosure Agreement only." The imprint for www.ethernut.de also clearly states "egnite Software GmbH assumes no responsibility for the contents of web sites that can be accessed through such links." If "Mr. Prism" calls me on Monday, I'll pass him to you. :-) No, seriously. This link may become a problem for home.kpnqwest.cz and anybody else who hosts this file for public access. It depends, of course, on local laws. But I wouldn't add it to the Ethernut download area. Harald From zodianet at wanadoo.fr Fri Feb 27 20:00:39 2004 From: zodianet at wanadoo.fr (Zodianet) Date: Fri, 27 Feb 2004 20:00:39 +0100 Subject: [En-Nut-Discussion] RE: [En-Nut-Discussion ] Prism Manuallink for anybody... In-Reply-To: <5.1.1.6.0.20040227182710.0335aec0@egnite.de> Message-ID: <20040227190251.A4D4818000C5@mwinf0802.wanadoo.fr> Please, Harald, pass Mr Prism to home.kpnqwest.cz, not me ;-) home.kpnqwest.cz takes his responsability. Of course, do not host this file yourself, without add-value. (Even if in fact, Prism 2.0... 3 chips are old and NDA has no meaning today). Jean Pierre -----Message d'origine----- De : en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de] De la part de Harald Kipp Envoy? : vendredi 27 f?vrier 2004 18:37 ? : Ethernut User Chat (English) Objet : Re: [En-Nut-Discussion] RE: [En-Nut-Discussion ] Prism Manuallink for anybody... Jean Pierre, you wrote > I think this link (found after 7'' with Google "RM0251 prim") is not under > NDA ;-) The very first sentence clearly states: "For distribution under a Non-Disclosure Agreement only." The imprint for www.ethernut.de also clearly states "egnite Software GmbH assumes no responsibility for the contents of web sites that can be accessed through such links." If "Mr. Prism" calls me on Monday, I'll pass him to you. :-) No, seriously. This link may become a problem for home.kpnqwest.cz and anybody else who hosts this file for public access. It depends, of course, on local laws. But I wouldn't add it to the Ethernut download area. Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From jesperh at telia.com Fri Feb 27 20:10:05 2004 From: jesperh at telia.com (Jesper Hansen) Date: Fri, 27 Feb 2004 20:10:05 +0100 Subject: [En-Nut-Discussion] RE: [En-Nut-Discussion ] Prism Manuallink foranybody... References: <20040227190251.A4D4818000C5@mwinf0802.wanadoo.fr> Message-ID: <025901c3fd65$63b7cce0$6500a8c0@jeha> > (Even if in fact, Prism 2.0... 3 chips are old and NDA has no meaning > today). > Jean Pierre That's what we would like to think. Last year, I needed to buy 200.000 cards for a project and asked Intersil if I could sign the NDA and get the document. Obviously, this was completely impossible. Sadly, as such a treatment would make me happy to change to another chipset, the situation is the same, so I'm stuck with the Prism2, due to the availability of Linux drivers, code from IOSoft and the now sudden appearance of this document. So they get to sell the chips anyway :-( /Jesper From zodianet at wanadoo.fr Fri Feb 27 21:59:43 2004 From: zodianet at wanadoo.fr (Zodianet) Date: Fri, 27 Feb 2004 21:59:43 +0100 Subject: [En-Nut-Discussion] RE: [En-Nut-Discussion ] Prism Manuallinkforanybody... In-Reply-To: <025901c3fd65$63b7cce0$6500a8c0@jeha> Message-ID: <20040227210156.4E71A1800195@mwinf0802.wanadoo.fr> Yes, I remarked that too. Incredible. 802.11 chip-sets world appairs very "closed" ... and too closed to PC mass market and subject to Asian copies. Perhaps, Broadcom will follow (http://www.broadcom.com/products/category.php?category_id=40) another marketing strategy? JP That's what we would like to think. Last year, I needed to buy 200.000 cards for a project and asked Intersil if I could sign the NDA and get the document. Obviously, this was completely impossible. Sadly, as such a treatment would make me happy to change to another chipset, the situation is the same, so I'm stuck with the Prism2, due to the availability of Linux drivers, code from IOSoft and the now sudden appearance of this document. So they get to sell the chips anyway :-( /Jesper _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From olischulz at web.de Sat Feb 28 21:41:14 2004 From: olischulz at web.de (Oliver Schulz) Date: Sat, 28 Feb 2004 21:41:14 +0100 Subject: [En-Nut-Discussion] Bugfixes from today In-Reply-To: <20040227133941.9D6FB18001AD@mwinf0801.wanadoo.fr> Message-ID: <000801c3fe3b$35f28e40$5b42a8c0@ose.de> Hello all, I just commited some bugfixes to nut-3_4-release and HEAD into CVS: * net/tcpsm.c: Bugfix in several tcp state functions. Swapped around the check for ACK and SYN flag. Because initial SYN packets don't have an ACK flag, recevied SYN packets were never rejected. This bug was discovered by Damian Slee. It seems, that tcp stack is now more reliable. Heavily stressed httpd application doesn't loose tcp sockets any more. * pro/resolv.c: Memory leak fixed in CreateDnsQuestion. Bugfix by Jean Pierre Gauthier. On re-creating the structure for dns question, some previously allocated memory was not released. * crt/getf.c: Several bugfixes from Francois Rademeyer applied. - "%%" didn't work. - integer parsing corrected. - support for "%u". Many thanks to all the authors and testers, who help us to build a reliable Nut/OS!!! Cheers, Oliver. From laing at bigpond.net.au Sun Feb 1 08:29:52 2004 From: laing at bigpond.net.au (The Laing Family) Date: Sun, 01 Feb 2004 18:29:52 +1100 Subject: [En-Nut-Discussion] External Power SUpply In-Reply-To: <000b01c3e821$3e646ec0$0100a8c0@ikarus2> Message-ID: Hi, This is probably a dumb question, but I HAVE read the doco and been unable to find enlightenment there. How do you power an Ethernut 2 board from an external 5V power supply? I know the simple answer is you use the screw terminals next to the RS 485 jumper block, and you jumper together pins 1 and 2, and pins 3 and 4. But which polarity do you connect to which screw terminal?! I'm very heistant to simply experiment after Harald's dire warnings of the likely consequences!! Thanks, Simon From harald.kipp at egnite.de Sun Feb 1 11:30:18 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Sun, 01 Feb 2004 11:30:18 +0100 Subject: [En-Nut-Discussion] CVS Release Branch 3.4 Occured In-Reply-To: <000b01c3e821$3e646ec0$0100a8c0@ikarus2> References: <5.1.1.6.0.20040130140149.03111e08@egnite.de> Message-ID: <5.1.1.6.0.20040201112815.01b91210@egnite.de> Hi Marc, At 18:39 31.01.2004 +0100, you wrote: >For what I dont understand is why there are differences (right now as of >2004-01-31) > between the nut-3_4-branch branch and the nut-3_4-release branch. >(cvs diff -r nut-3_4-branch nut) Did you update the checked out nut-3_4-release branch? There will be a difference in os/version.c and appload/. Harald From harald.kipp at egnite.de Sun Feb 1 11:43:02 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Sun, 01 Feb 2004 11:43:02 +0100 Subject: [En-Nut-Discussion] External Power SUpply In-Reply-To: References: <000b01c3e821$3e646ec0$0100a8c0@ikarus2> Message-ID: <5.1.1.6.0.20040201113242.01b91358@egnite.de> Hi Simon, You do right using extreme caution. 5V supply is possible only at the expansion port. But you may have to protect IC8, I assume. The screw terminal supply is connected to DC, which is after the rectifier bridge but before the regulator. Setting jumpers on JP6 1-2 and 3-4 will disable the diode and R26 as required. Contacts 3 of the terminal should be connected to minus (GND) and contact 4 to plus (7V) of your power supply. Contact 4 is the one near the mounting hole. To make sure you got the right contacts, supply the board with the barrel connector and measure the screw terminal contacts. You'll find the same polarity there. Harald At 18:29 01.02.2004 +1100, you wrote: >Hi, > >This is probably a dumb question, but I HAVE read the doco and been unable >to find enlightenment there. > >How do you power an Ethernut 2 board from an external 5V power supply? I >know the simple answer is you use the screw terminals next to the RS 485 >jumper block, and you jumper together pins 1 and 2, and pins 3 and 4. But >which polarity do you connect to which screw terminal?! I'm very heistant to >simply experiment after Harald's dire warnings of the likely consequences!! > >Thanks, > >Simon > >_______________________________________________ >En-Nut-Discussion mailing list >En-Nut-Discussion at egnite.de >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From harald.kipp at egnite.de Sun Feb 1 20:38:17 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Sun, 01 Feb 2004 20:38:17 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms Message-ID: <5.1.1.6.0.20040201202852.0325d438@egnite.de> Hi, Some files in CVS had been split by CPU families: os/timer.c: tmr_arm.c tmr_avr.c tmr_h8.c tmr_m68k.c os/thread.c: ctx_arm.c ctx_avr.c ctx_h8.c ctx_m68k.c In addition include/compiler.h had been split into files located in subdir include/cpu/. These changes are far from compilability, except AVRGCC. Other candidates are 1. Atomic functions 2. Enter/Exit critical functions 3. Checksum calculation 4. Interrupt stuff I have currently now idea, wich compilers I should chose in the first place for ARM7TDMI, H8/300 or Coldfire. Linux seems to be no big problem. Can anybody recommend any pre-build binaries for Win32? Thanks, Harald From damian at commtech.com.au Mon Feb 2 01:28:17 2004 From: damian at commtech.com.au (Damian Slee) Date: Mon, 2 Feb 2004 08:28:17 +0800 Subject: [En-Nut-Discussion] Supporting Other Target Platforms Message-ID: I'm not sure if this helps, there appears to be toolchains for ARM on the eCos site. Haven't used them though. http://ecos.sourceware.org/getstart.html -----Original Message----- From: Harald Kipp [mailto:harald.kipp at egnite.de] Sent: Monday, 2 February 2004 3:38 AM To: Ethernut User Chat (English) Subject: [En-Nut-Discussion] Supporting Other Target Platforms Hi, Some files in CVS had been split by CPU families: os/timer.c: tmr_arm.c tmr_avr.c tmr_h8.c tmr_m68k.c os/thread.c: ctx_arm.c ctx_avr.c ctx_h8.c ctx_m68k.c In addition include/compiler.h had been split into files located in subdir include/cpu/. These changes are far from compilability, except AVRGCC. Other candidates are 1. Atomic functions 2. Enter/Exit critical functions 3. Checksum calculation 4. Interrupt stuff I have currently now idea, wich compilers I should chose in the first place for ARM7TDMI, H8/300 or Coldfire. Linux seems to be no big problem. Can anybody recommend any pre-build binaries for Win32? Thanks, Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From ngbmoreau at yahoo.com.au Mon Feb 2 01:32:45 2004 From: ngbmoreau at yahoo.com.au (NGB) Date: Mon, 2 Feb 2004 11:32:45 +1100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <5.1.1.6.0.20040201202852.0325d438@egnite.de> References: <5.1.1.6.0.20040201202852.0325d438@egnite.de> Message-ID: <1075681965.401d9aadb4f5c@tiger.enttec> Harald I have scripts to build a arm-elf with newlib tool chain, they work under Linux and Cygwin. If you do use a pre built binary make sure you know how it was built, otherwsie it can lead to hours of fustration. email me if you want the scripts, they are based on crosstool-0.25 Nic > I have currently now idea, wich compilers I should > chose in the first place for ARM7TDMI, H8/300 or Coldfire. > Linux seems to be no big problem. > Can anybody recommend any pre-build binaries for Win32? ------------------------------------------------- From enut at ixo.de Mon Feb 2 09:10:18 2004 From: enut at ixo.de (Waschk,Kolja) Date: Mon, 2 Feb 2004 09:10:18 +0100 (CET) Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <5.1.1.6.0.20040201202852.0325d438@egnite.de> References: <5.1.1.6.0.20040201202852.0325d438@egnite.de> Message-ID: > wich compilers I should > chose in the first place for ARM7TDMI, H8/300 or Coldfire. [...] > Can anybody recommend any pre-build binaries for Win32? http://www.OCDemon.com has GNU gcc 2.95.3+binutils+gdb/insight for ARM. They're popular for their JTAG adapters. The "Wiggler" is the very basic one, just level shifters on parallel port (cheapest ready made clone is ARM-JTAG from Olimex, http://www.olimex.com ). The OCDemon "Raven" is the most basic one with Linux host support (cheapest ready made clone is the Chameleon POD from Amontec, http://www.amontec.com ). Looking at ARM targets, I'd suggest to select a particular configuration and document this selection for first steps. There are so many options, e.g. little vs big endian memory, presence of MMU, FPU, ... Many of these options have to be taken into account when configuring and building the toolchain. For example, a lot of toolchains have a libc with floating point instructions that wouldn't even disappear if you give the proper "no-fpu" compile options. A reasonable configuration for an "ARM Ethernut" could be - ARM7 core (Architecture v4) - Thumb instructions available - MMU not available - FPU not available - little endian memory (seems to be more common) Regards, Kolja -- mr. kolja waschk - haubach-39 - 22765 hh - ger phone +49 40 889130-34 - fax -35 - e-mail s.a. From jdx at slackware.pl Mon Feb 2 03:15:57 2004 From: jdx at slackware.pl (Jan Dubiec) Date: 02 Feb 2004 03:15:57 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <5.1.1.6.0.20040201202852.0325d438@egnite.de> References: <5.1.1.6.0.20040201202852.0325d438@egnite.de> Message-ID: <87vfmqxm3m.fsf@hs001.slackware.pl> On Sun, 01 Feb 2004 20:38:17 +0100, Harald Kipp wrote: > Hi, > > Some files in CVS had been split by CPU families: > > os/timer.c: tmr_arm.c tmr_avr.c tmr_h8.c tmr_m68k.c > os/thread.c: ctx_arm.c ctx_avr.c ctx_h8.c ctx_m68k.c IMO there should be created "arch" directory with MCU/CPU dependent subdirectories in it - please look at arch directory in the Linux kernel sources as an example. Then the above files should be moved to appropriate subdirectories. So finally there should be two eg. timer.c files: first under "os" directory which should contain hardware independent functions and the second under eg. "arch/h8300" with hardware dependent stuff. Next, IMO it isn't elegant using #if defined(__AVR_ATmega128__) || defined(__AVR_ATmega103__) #include "tmr_avr.c" #elif defined(__arm__) #include "tmr_arm.c" #elif defined(__H8300__) #include "tmr_h8.c" #elif defined(__m68k__) #include "tmr_m68k.c" #endif IMO better solution is to compile all hardware dependent files separately and consolidate them into one library, let's say libarch.a. We should also take into account that different devices can be build on the same MCU/CPU, eg. there are different EVBs for H8/3068F. [.....] > Other candidates are > > 1. Atomic functions > 2. Enter/Exit critical functions > 3. Checksum calculation > 4. Interrupt stuff 5. os/nutinit.c 6. Serial port stuf (initialization, enabling/disabling and control) 7. EEPROM stuff - AFAIK avr-gcc and Imagecraft do supply library with appropriate functions, H8 gcc doesn't > I have currently now idea, wich compilers I should > chose in the first place for ARM7TDMI, H8/300 or Coldfire. Of course gcc. ;-) At least for H8/300H. > Linux seems to be no big problem. > Can anybody recommend any pre-build binaries for Win32? Please look at http://www.kpitgnutools.com - you can find there Linux and Windows gcc binaries for H8/300H and SuperH MCU families. In order to download them you have to create an account first. Regards, /J.D. -- Jan Dubiec, jdx at slackware.pl, mobile: +48 602 101787 G??boka wiara wymaga p?ytkiego rozumu i nik?ej wiedzy. From nut at imsystems.ru Mon Feb 2 10:45:01 2004 From: nut at imsystems.ru (Roman Avramenko) Date: Mon, 2 Feb 2004 12:45:01 +0300 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <87vfmqxm3m.fsf@hs001.slackware.pl> References: <87vfmqxm3m.fsf@hs001.slackware.pl> Message-ID: <4531.040202@imsystems.ru> Hello Jan, Monday, February 02, 2004, 5:15:57 AM, you wrote: >> os/timer.c: tmr_arm.c tmr_avr.c tmr_h8.c tmr_m68k.c >> os/thread.c: ctx_arm.c ctx_avr.c ctx_h8.c ctx_m68k.c JD> IMO there should be created "arch" directory with MCU/CPU dependent JD> subdirectories in it - please look at arch directory in the Linux JD> kernel sources as an example. Then the above files should be moved to JD> appropriate subdirectories. So finally there should be two eg. timer.c JD> files: first under "os" directory which should contain hardware independent JD> functions and the second under eg. "arch/h8300" with hardware dependent JD> stuff. Right, also I think it will be better to have common arch/armnommu directory with separate system subdirs: arch/armnommu/snds100 -> Samsung S3C4510 (and probably S3C4530) ARM arch/armnommu/netarm -> NetARM arch/armnommu/atmel -> Atmel AT91 etc.. -- Best regards, Roman mailto:nut at imsystems.ru From harald.kipp at egnite.de Mon Feb 2 11:43:32 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 02 Feb 2004 11:43:32 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <87vfmqxm3m.fsf@hs001.slackware.pl> References: <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040201202852.0325d438@egnite.de> Message-ID: <5.1.1.6.0.20040202112338.031f81d8@egnite.de> Hi Jan and others, At 03:15 02.02.2004 +0100, you wrote: >On Sun, 01 Feb 2004 20:38:17 +0100, Harald Kipp wrote: > > Hi, > > > > Some files in CVS had been split by CPU families: > > > > os/timer.c: tmr_arm.c tmr_avr.c tmr_h8.c tmr_m68k.c > > os/thread.c: ctx_arm.c ctx_avr.c ctx_h8.c ctx_m68k.c >IMO there should be created "arch" directory with MCU/CPU dependent >subdirectories in it - please look at arch directory in the Linux >kernel sources as an example. Then the above files should be moved to >appropriate subdirectories. So finally there should be two eg. timer.c >files: first under "os" directory which should contain hardware independent >functions and the second under eg. "arch/h8300" with hardware dependent Frankly, most posters vote for the structure used with Linux, but without actually pointing to any advantage. Btw. "standard" is often a weak argument, IMO. >stuff. Next, IMO it isn't elegant using >#if defined(__AVR_ATmega128__) || defined(__AVR_ATmega103__) >#include "tmr_avr.c" >#elif defined(__arm__) >#include "tmr_arm.c" >#elif defined(__H8300__) >#include "tmr_h8.c" >#elif defined(__m68k__) >#include "tmr_m68k.c" >#endif >IMO better solution is to compile all hardware dependent files >separately and consolidate them into one library, let's say libarch.a. No, it isn't elegant but proofed in dev/usart.c to produce the least duplicate code. On the other hand, creating hardware dependant libraries simplifies the make process configuration. >We should also take into account that different devices can be build >on the same MCU/CPU, eg. there are different EVBs for H8/3068F. > >[.....] > > Other candidates are > > > > 1. Atomic functions > > 2. Enter/Exit critical functions > > 3. Checksum calculation > > 4. Interrupt stuff >5. os/nutinit.c >6. Serial port stuf (initialization, enabling/disabling and control) >7. EEPROM stuff - AFAIK avr-gcc and Imagecraft do supply library with > appropriate functions, H8 gcc doesn't OK. > > I have currently now idea, wich compilers I should > > chose in the first place for ARM7TDMI, H8/300 or Coldfire. >Of course gcc. ;-) At least for H8/300H. As far as I found out, almost all ARM compilers are GCC. But there seem to be different binary distributions, at least for the Win32 platform. For most Linux flavors building the toolchain is simple. But on Windows this might be a pain. > > Linux seems to be no big problem. > > Can anybody recommend any pre-build binaries for Win32? >Please look at http://www.kpitgnutools.com - you can find there Linux >and Windows gcc binaries for H8/300H and SuperH MCU families. In order >to download them you have to create an account first. Any good reason, why to prefer this one? Thanks, Harald From harald.kipp at egnite.de Mon Feb 2 12:03:53 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 02 Feb 2004 12:03:53 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <1075681965.401d9aadb4f5c@tiger.enttec> References: <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040201202852.0325d438@egnite.de> Message-ID: <5.1.1.6.0.20040202114503.01c28218@egnite.de> Hi Nic, At 11:32 02.02.2004 +1100, you wrote: >I have scripts to build a arm-elf with newlib tool chain, they work under >Linux >and Cygwin. I'd prefer MingW to avoid these DLL conflicts, but Cygwin seems to be supported by default. >If you do use a pre built binary make sure you know how it was built, >otherwsie >it can lead to hours of fustration. While doing the first steps with arm-gcc, I was hit by the fact, that I had to modify the linker files to get the program compiled for a specific ARM CPU. IMO, this is unacceptable for most Nut/OS users. >email me if you want the scripts, they are based on crosstool-0.25 Many thanks for your offer to help. I can accept to build my own binaries, but I'll never be able to support this for other users. Most Nut/OS newbies will not distinguish between Nut related topics and problems with their GCC build. If you look to this mailing list's archives, many questions are related to AVR chips, HTML/CGI problems or even the C language in general. I'd like to keep the steps towards the first running program as simple as possible. Today's newbies are tomorrow's gurus, if they don't get frustrated in the first five minutes. Harald From harald.kipp at egnite.de Mon Feb 2 12:23:06 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 02 Feb 2004 12:23:06 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <5.1.1.6.0.20040201202852.0325d438@egnite.de> Message-ID: <5.1.1.6.0.20040202122205.01c385b0@egnite.de> > >I have currently now idea, wich compilers I should Did I write this wonderfully crafted piece of crap? :-) Harald From harald.kipp at egnite.de Mon Feb 2 12:19:45 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 02 Feb 2004 12:19:45 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: References: <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040201202852.0325d438@egnite.de> Message-ID: <5.1.1.6.0.20040202120557.03268890@egnite.de> Hi Kolja, At 09:10 02.02.2004 +0100, Waschk,Kolja wrote: > > wich compilers I should > > chose in the first place for ARM7TDMI, H8/300 or Coldfire. [...] > > Can anybody recommend any pre-build binaries for Win32? > >http://www.OCDemon.com has GNU gcc 2.95.3+binutils+gdb/insight for ARM. Isn't 2.95 a little bit outdated? >Looking at ARM targets, I'd suggest to select a particular configuration >and document this selection for first steps. There are so many options, e.g. >little vs big endian memory, presence of MMU, FPU, ... Many of these options >have to be taken into account when configuring and building the toolchain. >For example, a lot of toolchains have a libc with floating point instructions >that wouldn't even disappear if you give the proper "no-fpu" compile options. That's also my experience with arm-gcc. And I think it is neccessary to have something pre-configured for Windows, if this exists. On Linux a well documented build process is sufficient. No idea, how's the situation with OS/X, but I guess it's similar to Linux up to a certain extend. Being forced to install the full Cygwin development toolchain and watching tons of warnings while the cross compiler is build, wouldn't attract many potential users. >A reasonable configuration for an "ARM Ethernut" could be > > - ARM7 core (Architecture v4) > - Thumb instructions available > - MMU not available > - FPU not available > - little endian memory (seems to be more common) We selected the AT91R40008 for the first step. I expected something other than Atmel again, and other chips are superior in many aspects (DMA, more IOs). But the 256k internal RAM is the killer argument. Harald From hyun at argostech.co.kr Mon Feb 2 12:58:55 2004 From: hyun at argostech.co.kr (Lee hyun-Keun) Date: Mon, 2 Feb 2004 20:58:55 +0900 Subject: [En-Nut-Discussion] NutTcpConnect() question. Message-ID: <003c01c3e983$ef31ed00$0200a8c0@narcisse> Hi, everyone. I'm new to this mailing list and to ethernut, I'm calling for your help... ;-) After some verification of my homemade hardware with your sample applications, I modified tcps.c to make it a tcp client. But if NutTcpConnect() is called when there is no server program listent on the port, the function never returns... i.e. 1) start server program first. turn on ethernut after : O.K. 2) turn on ethernut first, start server program after : Blocked on NutTcpConnect. packets captured on case (1) with ethereal shows: ethernut -> server port4097 > port7050 [SYN] Seq=1000000 Ack=0 Win=3216 Len=0 server->ethernut port7050 > port 4097 [RST, ACK] Seq=0 Ack=1000001 Win=0 Len=0 Thanks in advance for your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Oliver.Schulz at bong.de Mon Feb 2 13:22:33 2004 From: Oliver.Schulz at bong.de (Oliver Schulz) Date: Mon, 2 Feb 2004 13:22:33 +0100 Subject: AW: [En-Nut-Discussion] NutTcpConnect() question. Message-ID: Hi Lee, this bug should be fixed in version 3.4.x. Which version of Nut/OS are you using? Look in os/version.c. Obtain the latest release from http://www.ethernut.de Cheers, Oliver. -----Ursprungliche Nachricht----- Von: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Lee hyun-Keun Gesendet: Montag, 2. Februar 2004 12:59 An: en-nut-discussion at egnite.de Betreff: [En-Nut-Discussion] NutTcpConnect() question. Hi, everyone. I'm new to this mailing list and to ethernut, I'm calling for your help... ;-) After some verification of my homemade hardware with your sample applications, I modified tcps.c to make it a tcp client. But if NutTcpConnect() is called when there is no server program listent on the port, the function never returns... i.e. 1) start server program first. turn on ethernut after : O.K. 2) turn on ethernut first, start server program after : Blocked on NutTcpConnect. packets captured on case (1) with ethereal shows: ethernut -> server port4097 > port7050 [SYN] Seq=1000000 Ack=0 Win=3216 Len=0 server->ethernut port7050 > port 4097 [RST, ACK] Seq=0 Ack=1000001 Win=0 Len=0 Thanks in advance for your help. From dferbas at dfsoft.cz Mon Feb 2 15:33:51 2004 From: dferbas at dfsoft.cz (Dusan Ferbas) Date: Mon, 02 Feb 2004 15:33:51 +0100 Subject: [En-Nut-Discussion] Re: Supporting Other Target Platforms In-Reply-To: <20040202112315.2BD2D2F42A5@p15095813.pureserver.info> References: <20040202112315.2BD2D2F42A5@p15095813.pureserver.info> Message-ID: <6.0.1.1.2.20040202152843.01bac290@pop3.servery.cz> If you want to build a Coldfire context switching it should be noticed that some of 68k instructions are not supported. Most important is absence of auto increment/decrement for movem. Maybe Coldfire will have diffferent low level module. No idea about free 68k compiler. I am using Metrowerks Codewarrior. >Some files in CVS had been split by CPU families: > >os/timer.c: tmr_arm.c tmr_avr.c tmr_h8.c tmr_m68k.c >os/thread.c: ctx_arm.c ctx_avr.c ctx_h8.c ctx_m68k.c Dusan From harald.kipp at egnite.de Mon Feb 2 15:52:43 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 02 Feb 2004 15:52:43 +0100 Subject: [En-Nut-Discussion] Version 3.4 Useful? Message-ID: <5.1.1.6.0.20040202154245.031ee2f0@egnite.de> First let me defend Lee: There's no official release of 3.4 yet, just a CVS snapshot. Talking about it, I'm wondering, who is actually using this release. Success reports by private email prefered. Please report problems here in the list. We just tested PPP in general and Shoutcast MP3 streaming over Ethernet. With MP3 we get hick-ups, which are typical for missing data. I can say for sure that the problem is not with the VS1001 driver. It's either caused by buffering or by TCP. We are using MSS of 1460 and 11680 bytes of window size. Harald From Baranov at intech21.com Mon Feb 2 15:56:28 2004 From: Baranov at intech21.com (Alexander Baranov) Date: Mon, 2 Feb 2004 09:56:28 -0500 Subject: [En-Nut-Discussion] Question about two network connections. Message-ID: <00bc01c3e99c$bcfdb760$1101000a@Alex> Hi, All. I have such a problem: I use two network oriented threads. Main thread periodically sends data through Inet using POST method of http protocol. Having sent the next potion of data, it obtains something as server reply and parses it as server command. Another thread, which I call DirectTCP, opens another socket and accepts data from port 23 - telnet like this: NutTcpAccept(dirsock, 23). It is supposed to be used for immediate incoming commands from the server. Actually, it works but sometimes it hangs up and the box is being reloaded by watchdog. I tried to investigate the situation and found that the 'tdp->td_memory' of the main thread after some time becomes not equal to DEADBEEF, which is interpreted as "CORRUPT" in one of the examples. I tried to free as much heap as possible and now I have almost 16K heap available, but I have not achieved stable work still. Maybe I have to upgrade the system? Judging from version.c I use 3.3.0.1. now. Please, advise. Thanks, Alexander Baranov From Oliver.Schulz at bong.de Mon Feb 2 16:38:42 2004 From: Oliver.Schulz at bong.de (Oliver Schulz) Date: Mon, 2 Feb 2004 16:38:42 +0100 Subject: AW: [En-Nut-Discussion] Version 3.4 Useful? Message-ID: Hi, > First let me defend Lee: There's no official > release of 3.4 yet, just a CVS snapshot. Right, I forgot about it. I fixed this bug in version 1.8 of net/tcpsm.c. If the tcp state machine is in TCPS_SYN_SENT state and a RST packet is received, the error code was set properly, but the caller of NutConnect wasn't noticed. So the call never returned. Cheers, Oliver. From lakab at telia.com Mon Feb 2 21:29:19 2004 From: lakab at telia.com (Lars Andersson) Date: Mon, 2 Feb 2004 21:29:19 +0100 Subject: [En-Nut-Discussion] POST method. In-Reply-To: <00bc01c3e99c$bcfdb760$1101000a@Alex> Message-ID: <002e01c3e9cb$3c1afb60$1601a8c0@p3> Hi all, a question triggered by Alexander Baranov's message today. Is there an example showing how to retrieve the query when using the POST method with CGI. This might not be the correct terminology but I hope you understand what I mean. I use GET with CGI but am bothered with the 256 byte limit. // Lars H. Andersson From Baranov at intech21.com Mon Feb 2 21:49:04 2004 From: Baranov at intech21.com (Alexander Baranov) Date: Mon, 2 Feb 2004 15:49:04 -0500 Subject: [En-Nut-Discussion] POST method. References: <002e01c3e9cb$3c1afb60$1601a8c0@p3> Message-ID: <001001c3e9cd$feaa0a70$1101000a@Alex> Hi, Lars. I am not sure that I've understood the question, but I can send you my code 'as is'. ----- Original Message ----- From: "Lars Andersson" To: "'Ethernut User Chat (English)'" Sent: Monday, February 02, 2004 3:29 PM Subject: [En-Nut-Discussion] POST method. > Hi all, > a question triggered by Alexander Baranov's message today. > > Is there an example showing how to retrieve the query when using > the POST method with CGI. This might not be the correct terminology > but I hope you understand what I mean. > > I use GET with CGI but am bothered with the 256 byte limit. > > // > Lars H. Andersson > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From lakab at telia.com Mon Feb 2 22:13:59 2004 From: lakab at telia.com (Lars Andersson) Date: Mon, 2 Feb 2004 22:13:59 +0100 Subject: [En-Nut-Discussion] POST method. In-Reply-To: <001001c3e9cd$feaa0a70$1101000a@Alex> Message-ID: <000001c3e9d1$7991f0b0$1601a8c0@p3> Alexander, When I use a CGI page with "method=GET" I can pick up query items using NutHttpGetParameter() calls, but if I would use "method=POST" I do not know how (or where) to find the query. Example: FormTop_P[] = ""; I would like to say METHOD=\"POST\" instead. -----Original Message----- From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Alexander Baranov Sent: Monday, 02 February, 2004 21:49 To: Ethernut User Chat (English) Subject: Re: [En-Nut-Discussion] POST method. Hi, Lars. I am not sure that I've understood the question, but I can send you my code 'as is'. ----- Original Message ----- From: "Lars Andersson" To: "'Ethernut User Chat (English)'" Sent: Monday, February 02, 2004 3:29 PM Subject: [En-Nut-Discussion] POST method. > Hi all, > a question triggered by Alexander Baranov's message today. > > Is there an example showing how to retrieve the query when using > the POST method with CGI. This might not be the correct terminology > but I hope you understand what I mean. > > I use GET with CGI but am bothered with the 256 byte limit. > > // > Lars H. Andersson > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From lakab at telia.com Mon Feb 2 22:21:20 2004 From: lakab at telia.com (Lars Andersson) Date: Mon, 2 Feb 2004 22:21:20 +0100 Subject: [En-Nut-Discussion] Makefile automagic In-Reply-To: <000001c3e9d1$7991f0b0$1601a8c0@p3> Message-ID: <000201c3e9d2$80a05120$1601a8c0@p3> Hi group, Somewhere in the Make process this command line is generated rm httpd.elf can I suppress this in some way? I just can't find where it happens! Regards, Lars H. Andersson From Baranov at intech21.com Mon Feb 2 22:34:36 2004 From: Baranov at intech21.com (Alexander Baranov) Date: Mon, 2 Feb 2004 16:34:36 -0500 Subject: [En-Nut-Discussion] POST method. References: <000001c3e9d1$7991f0b0$1601a8c0@p3> Message-ID: <001a01c3e9d4$5ad8c4c0$1101000a@Alex> Hi. It seems to me that I've understood. I designed http client, sending http-requests, on Ethernut and http-server is made on remote web-server and is made by another developer on C#. And you AFAIU want to realize http-server on Ethernut . Sorry, I did not do that. Regards, Alex. ----- Original Message ----- From: "Lars Andersson" To: "'Ethernut User Chat (English)'" Sent: Monday, February 02, 2004 4:13 PM Subject: RE: [En-Nut-Discussion] POST method. > Alexander, > > When I use a CGI page with "method=GET" I > can pick up query items using NutHttpGetParameter() calls, > but if I would use "method=POST" I do not know > how (or where) to find the query. > > Example: > FormTop_P[] = " METHOD=\"GET\">"; > > I would like to say METHOD=\"POST\" instead. > > > > > -----Original Message----- > From: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Alexander > Baranov > Sent: Monday, 02 February, 2004 21:49 > To: Ethernut User Chat (English) > Subject: Re: [En-Nut-Discussion] POST method. > > > Hi, Lars. > I am not sure that I've understood the question, but I can send you my > code > 'as is'. > > ----- Original Message ----- > From: "Lars Andersson" > To: "'Ethernut User Chat (English)'" > Sent: Monday, February 02, 2004 3:29 PM > Subject: [En-Nut-Discussion] POST method. > > > > Hi all, > > a question triggered by Alexander Baranov's message today. > > > > Is there an example showing how to retrieve the query when using > > the POST method with CGI. This might not be the correct terminology > > but I hope you understand what I mean. > > > > I use GET with CGI but am bothered with the 256 byte limit. > > > > // > > Lars H. Andersson > > > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From enut at ixo.de Mon Feb 2 23:38:23 2004 From: enut at ixo.de (Waschk,Kolja) Date: Mon, 2 Feb 2004 23:38:23 +0100 (CET) Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <5.1.1.6.0.20040202120557.03268890@egnite.de> References: <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040202120557.03268890@egnite.de> Message-ID: Hi, > >http://www.OCDemon.com has GNU gcc 2.95.3+binutils+gdb/insight for ARM. > Isn't 2.95 a little bit outdated? In principle, yes. But unless you find a toolchain using 3.3 or 3.4 that isn't tagged "experimental", I'd recommend staying with 2.95.3. Especially if C++ isn't needed but just C and assembler. I agree that something like a WinAVR package for ARM would be really nice. However, I'm quite sure it wouldn't be a "WinARM" but rather a "WinAT91" or "WinLPC2X": "ARM" just isn't a synonym for some well-defined platform like "AVR" is. > We selected the AT91R40008 for the first step. > [...] > internal RAM is the killer argument. Probably it is wise to restrict ARM support in Nut/OS to platforms/CPUs that have something like this in common: no need for Megabytes of RAM nor ROM. >From my point of view, Nut/OS can provide an environment with threads and TCP/IP for targets with small memory. Anyone who has a "bigger" target could use uClinux or eCos or KADAK or ... Beside some Atmel CPUs, I'd like to see Philips LPC21xx supported. Yet they aren't available with external bus, but it is supposed to change soon. Even without external bus, having a TCP/IP stack can be useful with PPP etc... Kolja P.S. If you're wondering how I'm currently involved with both Nut/OS and ARM; I'm currently using Nut/OS on a Ethernut derivative that is supposed to add Ethernet connectivity to some industrial measurement device, and in parallel (for personal use only) work on adapting uClinux 2.4 and linux 2.6 to run on a ZyXEL router I happen to own (with Samsung S3C4510 CPU with ARM7TDMI). -- mr. kolja waschk - haubach-39 - 22765 hh - ger phone +49 40 889130-34 - fax -35 - e-mail s.a. From mikec at call-direct.com.au Mon Feb 2 23:45:10 2004 From: mikec at call-direct.com.au (Mike Cornelius) Date: Tue, 3 Feb 2004 09:45:10 +1100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <5.1.1.6.0.20040202112338.031f81d8@egnite.de> Message-ID: <01ec01c3e9de$37fdb050$2301a8c0@Mike> Jan Wrote:- >>Please look at http://www.kpitgnutools.com - you can find there Linux >>and Windows gcc binaries for H8/300H and SuperH MCU families. In order >>to download them you have to create an account first. Harald Wrote:- >Any good reason, why to prefer this one? Jan got in before me but I will second his sugestion. This is the toolchain I used when I ported Nut/OS to the H8 so the first reason to prefer it is that it's know to work, it installed without any trouble and I was up and running in only a few minutes. Secondly it's very well supported, KPIT are activly maintaining this release. Thirdly it is compatible with the HEW IDE which may be useful to some people. 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-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Harald Kipp Sent: Monday, February 02, 2004 9:44 PM To: Ethernut User Chat (English) Subject: Re: [En-Nut-Discussion] Supporting Other Target Platforms Hi Jan and others, At 03:15 02.02.2004 +0100, you wrote: >On Sun, 01 Feb 2004 20:38:17 +0100, Harald Kipp >wrote: > > Hi, > > > > Some files in CVS had been split by CPU families: > > > > os/timer.c: tmr_arm.c tmr_avr.c tmr_h8.c tmr_m68k.c > > os/thread.c: ctx_arm.c ctx_avr.c ctx_h8.c ctx_m68k.c >IMO there should be created "arch" directory with MCU/CPU dependent >subdirectories in it - please look at arch directory in the Linux >kernel sources as an example. Then the above files should be moved to >appropriate subdirectories. So finally there should be two eg. timer.c >files: first under "os" directory which should contain hardware >independent functions and the second under eg. "arch/h8300" with >hardware dependent Frankly, most posters vote for the structure used with Linux, but without actually pointing to any advantage. Btw. "standard" is often a weak argument, IMO. >stuff. Next, IMO it isn't elegant using >#if defined(__AVR_ATmega128__) || defined(__AVR_ATmega103__) #include >"tmr_avr.c" #elif defined(__arm__) >#include "tmr_arm.c" >#elif defined(__H8300__) >#include "tmr_h8.c" >#elif defined(__m68k__) >#include "tmr_m68k.c" >#endif >IMO better solution is to compile all hardware dependent files >separately and consolidate them into one library, let's say libarch.a. No, it isn't elegant but proofed in dev/usart.c to produce the least duplicate code. On the other hand, creating hardware dependant libraries simplifies the make process configuration. >We should also take into account that different devices can be build on >the same MCU/CPU, eg. there are different EVBs for H8/3068F. > >[.....] > > Other candidates are > > > > 1. Atomic functions > > 2. Enter/Exit critical functions > > 3. Checksum calculation > > 4. Interrupt stuff >5. os/nutinit.c >6. Serial port stuf (initialization, enabling/disabling and control) 7. >EEPROM stuff - AFAIK avr-gcc and Imagecraft do supply library with > appropriate functions, H8 gcc doesn't OK. > > I have currently now idea, wich compilers I should > > chose in the first place for ARM7TDMI, H8/300 or Coldfire. >Of course gcc. ;-) At least for H8/300H. As far as I found out, almost all ARM compilers are GCC. But there seem to be different binary distributions, at least for the Win32 platform. For most Linux flavors building the toolchain is simple. But on Windows this might be a pain. > > Linux seems to be no big problem. > > Can anybody recommend any pre-build binaries for Win32? >Please look at http://www.kpitgnutools.com - you can find there Linux >and Windows gcc binaries for H8/300H and SuperH MCU families. In order >to download them you have to create an account first. Any good reason, why to prefer this one? Thanks, Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From ngbmoreau at yahoo.com.au Mon Feb 2 23:52:32 2004 From: ngbmoreau at yahoo.com.au (NGB) Date: Tue, 3 Feb 2004 09:52:32 +1100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: References: <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040202120557.03268890@egnite.de> Message-ID: <1075762352.401ed4b04f3ab@tiger.enttec> > > In principle, yes. But unless you find a toolchain using 3.3 or 3.4 that > isn't > tagged "experimental", I'd recommend staying with 2.95.3. Especially if C++ > isn't needed but just C and assembler. I'm pretty sure GCC 3.3 has been tagged stable for ARM, a quick check on the arm linux malining list should confirm this. Nic ------------------------------------------------- From hyun at argostech.co.kr Tue Feb 3 02:26:52 2004 From: hyun at argostech.co.kr (Lee hyun-Keun) Date: Tue, 3 Feb 2004 10:26:52 +0900 Subject: [En-Nut-Discussion] POST method. References: <000001c3e9d1$7991f0b0$1601a8c0@p3> Message-ID: <003301c3e9f4$cd7eff10$0200a8c0@narcisse> To Lars, To get cgi input posted using POST method, I read from stdin up to the length obtained from : getenv("CONTENT_LENGTH") call in linux. You should perhaps find how to do it in Ethernut. Cheers ----- Original Message ----- From: "Lars Andersson" To: "'Ethernut User Chat (English)'" Sent: Tuesday, February 03, 2004 6:13 AM Subject: RE: [En-Nut-Discussion] POST method. > Alexander, > > When I use a CGI page with "method=GET" I > can pick up query items using NutHttpGetParameter() calls, > but if I would use "method=POST" I do not know > how (or where) to find the query. > > Example: > FormTop_P[] = " METHOD=\"GET\">"; > > I would like to say METHOD=\"POST\" instead. > > > > > -----Original Message----- > From: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Alexander > Baranov > Sent: Monday, 02 February, 2004 21:49 > To: Ethernut User Chat (English) > Subject: Re: [En-Nut-Discussion] POST method. > > > Hi, Lars. > I am not sure that I've understood the question, but I can send you my > code > 'as is'. > > ----- Original Message ----- > From: "Lars Andersson" > To: "'Ethernut User Chat (English)'" > Sent: Monday, February 02, 2004 3:29 PM > Subject: [En-Nut-Discussion] POST method. > > > > Hi all, > > a question triggered by Alexander Baranov's message today. > > > > Is there an example showing how to retrieve the query when using > > the POST method with CGI. This might not be the correct terminology > > but I hope you understand what I mean. > > > > I use GET with CGI but am bothered with the 256 byte limit. > > > > // > > Lars H. Andersson > > > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From enut at ixo.de Tue Feb 3 07:54:31 2004 From: enut at ixo.de (Waschk,Kolja) Date: Tue, 3 Feb 2004 07:54:31 +0100 (CET) Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <1075762352.401ed4b04f3ab@tiger.enttec> References: <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040202120557.03268890@egnite.de> <1075762352.401ed4b04f3ab@tiger.enttec> Message-ID: ngb> I'm pretty sure GCC 3.3 has been tagged stable for ARM The 3.3 gcc itself is, i.e. it produces correct assembler files from C - but Harald asked for a prebuilt toolchain, i.e. something that is also correctly assembling and linking. I met some basic problems when building a 3.3 + uclibc toolchain that would suit my particular target (big endian ARM without MMU and without FPU). That makes me wonder if available toolchains really have that all sorted out yet. Kolja -- mr. kolja waschk - haubach-39 - 22765 hh - ger phone +49 40 889130-34 - fax -35 - e-mail s.a. From bengt at florin.se Tue Feb 3 08:06:15 2004 From: bengt at florin.se (Bengt Florin) Date: Tue, 3 Feb 2004 08:06:15 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <1075762352.401ed4b04f3ab@tiger.enttec> Message-ID: <00d201c3ea24$3748dc70$0205a8c0@hugin> Found this for gcc 3.3.2 & 3.4. IIRC Harald doesn't like CygWin, but this is what you get. http://www.ariusdsp.com/gnuarm/gnuarm.html bengan -----Original Message----- From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de]On Behalf Of NGB Sent: den 2 februari 2004 23:53 To: enut at ixo.de; Ethernut User Chat (English) Subject: Re: [En-Nut-Discussion] Supporting Other Target Platforms > > In principle, yes. But unless you find a toolchain using 3.3 or 3.4 that > isn't > tagged "experimental", I'd recommend staying with 2.95.3. Especially if C++ > isn't needed but just C and assembler. I'm pretty sure GCC 3.3 has been tagged stable for ARM, a quick check on the arm linux malining list should confirm this. Nic ------------------------------------------------- _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From mwse at gmx.de Tue Feb 3 08:17:16 2004 From: mwse at gmx.de (Marc Wetzel) Date: Tue, 3 Feb 2004 08:17:16 +0100 Subject: [En-Nut-Discussion] Makefile automagic In-Reply-To: <000201c3e9d2$80a05120$1601a8c0@p3> Message-ID: <003601c3ea25$c1029f90$6401a8c0@ikarus2> For a one-shot I use `make httpd.elf` to get the file not deleted. /Marc > -----Original Message----- > From: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of > Lars Andersson > Sent: Monday, February 02, 2004 10:21 PM > To: 'Ethernut User Chat (English)' > Subject: [En-Nut-Discussion] Makefile automagic > > > Hi group, > > Somewhere in the Make process > this command line is generated > > rm httpd.elf > > can I suppress this in some way? > I just can't find where it happens! > > > Regards, > Lars H. Andersson > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-> nut-discussion > From ngbmoreau at yahoo.com.au Tue Feb 3 08:32:42 2004 From: ngbmoreau at yahoo.com.au (NGB) Date: Tue, 3 Feb 2004 18:32:42 +1100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <00d201c3ea24$3748dc70$0205a8c0@hugin> References: <00d201c3ea24$3748dc70$0205a8c0@hugin> Message-ID: <1075793562.401f4e9aaf19e@tiger.enttec> This one looks really good. But I suspect they have used the standard newlib, which needs to be hacked and rebuilt because the crt0.s file relies heavily on the ARM monitor (HaL I think). Harald I'm not sure you will be able to find an prebuilt toolchain for ARM that is as clean as Winavr. But this should not stop development on a Ethernut 4 ARM. Nic Quoting Bengt Florin : > Found this for gcc 3.3.2 & 3.4. > IIRC Harald doesn't like CygWin, but this is what you get. > > http://www.ariusdsp.com/gnuarm/gnuarm.html > > bengan ------------------------------------------------- From unreal at home.nl Tue Feb 3 00:12:10 2004 From: unreal at home.nl (Michel) Date: Tue, 3 Feb 2004 00:12:10 +0100 Subject: [En-Nut-Discussion] PPP fixes In-Reply-To: <01ec01c3e9de$37fdb050$2301a8c0@Mike> Message-ID: <002b01c3e9e1$fc84a250$6400a8c0@imhotep> Hi all, As promised, here are my fixes for PPP. Sorry it took so long :-) The last fixes I posted did not fix the case where an option that was rejected was longer than the option just in the front of it. Basically what I did was fix the CONFREJ by moving all remaining options to the front of the packet, not just the one being rejected. In NutLcpInput() and in NutPapInput() I also made a small improvement by setting the size of the network layer (nb_nw.sz) to the correct value. Although this didn't seem to be harmfull in any way, maybe it will prevent any future problems. These fixes have enabled me to succesfully dialin to some of the larger Dutch ISP's. To my regret, I noticed that I missed the closing date for an official release by just a few days. Ah well, better luck next time :-) Greetings Michel Hendriks -------------- next part -------------- A non-text attachment was scrubbed... Name: icmpin.c Type: application/octet-stream Size: 6590 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lcpin.c Type: application/octet-stream Size: 17126 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: papin.c Type: application/octet-stream Size: 4695 bytes Desc: not available URL: From unreal at home.nl Tue Feb 3 00:23:43 2004 From: unreal at home.nl (Michel) Date: Tue, 3 Feb 2004 00:23:43 +0100 Subject: [En-Nut-Discussion] PPP fixes Message-ID: <006001c3e9e3$99365a70$6400a8c0@imhotep> And this time with the correct files.... > -----Original Message----- > From: Michel [mailto:unreal at home.nl] > Sent: dinsdag 3 februari 2004 0:12 > To: 'Ethernut User Chat (English)' > Subject: PPP fixes > > > Hi all, > > As promised, here are my fixes for PPP. Sorry it took so long :-) > > The last fixes I posted did not fix the case where an option > that was rejected was longer than the option just in the front of it. > > Basically what I did was fix the CONFREJ by moving all remaining > options to the front of the packet, not just the one being rejected. > > In NutLcpInput() and in NutPapInput() I also made a small > improvement by setting the size of the network layer > (nb_nw.sz) to the correct value. Although this didn't seem to > be harmfull in any way, maybe it will prevent any future problems. > > These fixes have enabled me to succesfully dialin to some of > the larger Dutch ISP's. > > To my regret, I noticed that I missed the closing date for an > official release by just a few days. Ah well, better luck > next time :-) > > Greetings > > Michel Hendriks > -------------- next part -------------- A non-text attachment was scrubbed... Name: ppp.zip Type: application/octet-stream Size: 10515 bytes Desc: not available URL: From harald.kipp at egnite.de Tue Feb 3 10:12:03 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 03 Feb 2004 10:12:03 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: References: <5.1.1.6.0.20040202120557.03268890@egnite.de> <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040201202852.0325d438@egnite.de> <5.1.1.6.0.20040202120557.03268890@egnite.de> Message-ID: <5.1.1.6.0.20040203095334.03223460@egnite.de> Hi Kolja, At 23:38 02.02.2004 +0100, you wrote: >Hi, > > > >http://www.OCDemon.com has GNU gcc 2.95.3+binutils+gdb/insight for ARM. > > Isn't 2.95 a little bit outdated? > >In principle, yes. But unless you find a toolchain using 3.3 or 3.4 that isn't >tagged "experimental", I'd recommend staying with 2.95.3. Especially if C++ >isn't needed but just C and assembler. Good argument. >I agree that something like a WinAVR package for ARM would be really nice. >However, I'm quite sure it wouldn't be a "WinARM" but rather a "WinAT91" or >"WinLPC2X": > >"ARM" just isn't a synonym for some well-defined platform like "AVR" is. Right, and it would be no big deal to provide one or more linker scripts or similar configs, specifically designed for a few reference platforms. As long as we do not force everyone building a complete toolchain on Cygwin. > > We selected the AT91R40008 for the first step. > > [...] > > internal RAM is the killer argument. > >Probably it is wise to restrict ARM support in Nut/OS to platforms/CPUs that >have something like this in common: no need for Megabytes of RAM nor ROM. > >From my point of view, Nut/OS can provide an environment with threads and >TCP/IP for targets with small memory. Anyone who has a "bigger" target could >use uClinux or eCos or KADAK or ... My view as well. But there I received requests for larger Xscale CPUs too. The idea is, that they need a very fast CPU for a simple multimedia application but don't want to handle a large OS. But these are rare cases, I assume. >Beside some Atmel CPUs, I'd like to see Philips LPC21xx supported. Yet they >aren't available with external bus, but it is supposed to change soon. Even >without external bus, having a TCP/IP stack can be useful with PPP etc... Yes, Erik Lins also pointed me to these CPUs. >on a ZyXEL router I happen to own (with Samsung S3C4510 CPU with ARM7TDMI). :-) My family bought me a Gameboy Advanced as a Christmas present. After SimCity became boring, I'm wondering now, if I can get Nut/OS running on it. Harald From harald.kipp at egnite.de Tue Feb 3 09:50:33 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 03 Feb 2004 09:50:33 +0100 Subject: [En-Nut-Discussion] Makefile automagic In-Reply-To: <000201c3e9d2$80a05120$1601a8c0@p3> References: <000001c3e9d1$7991f0b0$1601a8c0@p3> Message-ID: <5.1.1.6.0.20040203094545.03225eb0@egnite.de> Lars, yeah, that's a funny thing and many users, including me, had been looking for this line in the Makefiles. In fact it isn't there. Make finds out, that it needs to create this file to build the final binary. But because it never appears on the final target list (unless you follow Marc's advice, entering 'make httpd.elf'), make deletes it after the binary is done. Or add it to the 'all' list in the Makefile. Harald At 22:21 02.02.2004 +0100, you wrote: >Hi group, > >Somewhere in the Make process >this command line is generated > >rm httpd.elf > >can I suppress this in some way? >I just can't find where it happens! From harald.kipp at egnite.de Tue Feb 3 10:19:08 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 03 Feb 2004 10:19:08 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <01ec01c3e9de$37fdb050$2301a8c0@Mike> References: <5.1.1.6.0.20040202112338.031f81d8@egnite.de> Message-ID: <5.1.1.6.0.20040203101607.01b9baa8@egnite.de> Mike, At 09:45 03.02.2004 +1100, you wrote: >Jan got in before me but I will second his sugestion. I'm convinced. You and Jan are the experts and no alternative has been suggested here. So we should go with http://www.kpitgnutools.com for the H8. Thanks, Harald From harald.kipp at egnite.de Tue Feb 3 10:35:54 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 03 Feb 2004 10:35:54 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <1075793562.401f4e9aaf19e@tiger.enttec> References: <00d201c3ea24$3748dc70$0205a8c0@hugin> <00d201c3ea24$3748dc70$0205a8c0@hugin> Message-ID: <5.1.1.6.0.20040203102115.01bb4fe8@egnite.de> Nic, At 18:32 03.02.2004 +1100, you wrote: >This one looks really good. But I suspect they have used the standard newlib, >which needs to be hacked and rebuilt because the crt0.s file relies >heavily on >the ARM monitor (HaL I think). >Harald I'm not sure you will be able to find an prebuilt toolchain for ARM >that >is as clean as Winavr. But this should not stop development on a Ethernut >4 ARM. No, of course not. I want to make sure, that as many people as possible can participate, no matter what their skills in configuring and building toolchains are or what kind of development environment they prefer. Many Nut/OS users are hardware freaks with limited software knowledge. May be, someone can setup a pre-build toolchain for a specific target platform and contribute it for download as a first, temporary step. Harald P.S. Personally I'll use Atmel's AT91EB40A Kit until my company designs a new Ethernut. From damian at commtech.com.au Tue Feb 3 13:59:55 2004 From: damian at commtech.com.au (Damian Slee) Date: Tue, 3 Feb 2004 20:59:55 +0800 Subject: [En-Nut-Discussion] Supporting Other Target Platforms Message-ID: i'd agree with the Atmel EB40A development board. It has the AT91R40008 with 256K ram on board and 2M flash external. The AT91FR40162 appears to be a copy of the AT92R40008 but with the 2M flash on chip. BGA package. Makes for a really really small design. However the Samsung one mentioned earlier with onboard LAN I have seen in the Linksys access points. But external flash and ram. -----Original Message----- From: Harald Kipp [mailto:harald.kipp at egnite.de] Sent: Tue 3/02/2004 5:35 PM To: Ethernut User Chat (English) Cc: Subject: RE: [En-Nut-Discussion] Supporting Other Target Platforms Nic, At 18:32 03.02.2004 +1100, you wrote: >This one looks really good. But I suspect they have used the standard newlib, >which needs to be hacked and rebuilt because the crt0.s file relies >heavily on >the ARM monitor (HaL I think). >Harald I'm not sure you will be able to find an prebuilt toolchain for ARM >that >is as clean as Winavr. But this should not stop development on a Ethernut >4 ARM. No, of course not. I want to make sure, that as many people as possible can participate, no matter what their skills in configuring and building toolchains are or what kind of development environment they prefer. Many Nut/OS users are hardware freaks with limited software knowledge. May be, someone can setup a pre-build toolchain for a specific target platform and contribute it for download as a first, temporary step. Harald P.S. Personally I'll use Atmel's AT91EB40A Kit until my company designs a new Ethernut. _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 5330 bytes Desc: not available URL: From harald.kipp at egnite.de Tue Feb 3 14:20:49 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 03 Feb 2004 14:20:49 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: Message-ID: <5.1.1.6.0.20040203141458.03303cf8@egnite.de> Damian, At 20:59 03.02.2004 +0800, you wrote: >The AT91FR40162 appears to be a copy of the AT92R40008 but with the 2M >flash on chip. BGA package. Makes for a really really small design. As far as I know this is a two die chip. Might be expensive. > >However the Samsung one mentioned earlier with onboard LAN I have seen in >the Linksys access points. But external flash and ram. Be aware that most of the onboard LANs are MAC only, no PHY. Harald From harald.kipp at egnite.de Tue Feb 3 14:30:30 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 03 Feb 2004 14:30:30 +0100 Subject: [En-Nut-Discussion] Question about two network connections. In-Reply-To: <00bc01c3e99c$bcfdb760$1101000a@Alex> Message-ID: <5.1.1.6.0.20040203142124.032c5838@egnite.de> Hi Alexander, This may be caused by many bugs. The system itself seems to be stable in this sense...but who knows. Recently a bug in netbuf.c had been detected, but it appears under very specific circumstances only. May be try a copy of this file from CVS. In the first place increase the stack size of your threads. This is easy. Next, carefully review your code, specially those parts, that write to allocated memory. The malloc routines in the debug version (NUTDEBUG) offer some additional protection and may help to locate the problem. If two threads are modifying multibyte values, make sure, that the modification is atomic. Most likely the problem is _not_ caused by too less heap space. Harald At 09:56 02.02.2004 -0500, you wrote: >Hi, All. >I have such a problem: >I use two network oriented threads. >Main thread periodically sends data through Inet using POST method of http >protocol. Having sent the next potion of data, it obtains something as >server reply and parses it as server command. >Another thread, which I call DirectTCP, opens another socket and accepts >data from port 23 - telnet like this: >NutTcpAccept(dirsock, 23). >It is supposed to be used for immediate incoming commands from the server. >Actually, it works but sometimes it hangs up and the box is being reloaded >by watchdog. I tried to investigate the situation and found that the >'tdp->td_memory' of the main thread after some time becomes not equal to >DEADBEEF, which is interpreted as "CORRUPT" in one of the examples. I tried >to free as much heap as possible and now I have almost 16K heap available, >but I have not achieved stable work still. >Maybe I have to upgrade the system? Judging from version.c I use 3.3.0.1. >now. Please, advise. >Thanks, >Alexander Baranov > >_______________________________________________ >En-Nut-Discussion mailing list >En-Nut-Discussion at egnite.de >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From conorduke at yahoo.co.uk Tue Feb 3 16:51:58 2004 From: conorduke at yahoo.co.uk (=?iso-8859-1?q?Conor=20Duke?=) Date: Tue, 3 Feb 2004 15:51:58 +0000 (GMT) Subject: [En-Nut-Discussion] undefined reference Message-ID: <20040203155158.92919.qmail@web25004.mail.ukl.yahoo.com> Dear Group , I tried recompliling my libraries but iu continually get the same error when i try to make this file the error is web808.o(.text+0x52): undefined reference to `devUsartAvr0' I can't seen to solve this bug,has any1 got any input? Regards Conor --------------------------------- Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now -------------- next part -------------- An HTML attachment was scrubbed... URL: From harald.kipp at egnite.de Tue Feb 3 17:31:05 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 03 Feb 2004 17:31:05 +0100 Subject: [En-Nut-Discussion] PPP fixes In-Reply-To: <006001c3e9e3$99365a70$6400a8c0@imhotep> Message-ID: <5.1.1.6.0.20040203170408.0321e1a0@egnite.de> Hi Michel, > > As promised, here are my fixes for PPP. Sorry it took so long :-) No problem, but I fear it's too late for 3.4.1. We already spend two days on the tests and just finished the Windows installation. Linux installation is being build right now. Your patches make sense to me, but I needed some time to get into the code again. Sigh, this PPP stuff is really weird. I'll add your changes to HEAD and, after some additional connection tests, to 3.4.2. Many thanks for the good job, Harald From harald.kipp at egnite.de Tue Feb 3 17:33:39 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 03 Feb 2004 17:33:39 +0100 Subject: [En-Nut-Discussion] undefined reference In-Reply-To: <20040203155158.92919.qmail@web25004.mail.ukl.yahoo.com> Message-ID: <5.1.1.6.0.20040203173142.032203f8@egnite.de> Conor, Either your Makefile or your nut libraries aren't up to date. Make sure that usartavr0.c is being linked into libnutdev.a. Harald At 15:51 03.02.2004 +0000, you wrote: >Dear Group , >I tried recompliling my libraries but iu continually get the same error >when i try to make this file >the error is >web808.o(.text+0x52): undefined reference to `devUsartAvr0' >I can't seen to solve this bug,has any1 got any input? >Regards >Conor From Baranov at intech21.com Tue Feb 3 20:25:55 2004 From: Baranov at intech21.com (Alexander Baranov) Date: Tue, 3 Feb 2004 14:25:55 -0500 Subject: [En-Nut-Discussion] Question about two network connections. References: <5.1.1.6.0.20040203142124.032c5838@egnite.de> Message-ID: <004401c3ea8b$8b5800e0$1101000a@Alex> Thanks, Harald. I suspect that the size of stack is the point. Could you tell me how to increase the size of stack of main thread or give me the reference to the doc? I could not find it using context search. Regards, Alex. ----- Original Message ----- From: "Harald Kipp" To: "Ethernut User Chat (English)" Sent: Tuesday, February 03, 2004 8:30 AM Subject: Re: [En-Nut-Discussion] Question about two network connections. > Hi Alexander, > > This may be caused by many bugs. The system itself > seems to be stable in this sense...but who knows. > Recently a bug in netbuf.c had been detected, but > it appears under very specific circumstances only. > May be try a copy of this file from CVS. > > In the first place increase the stack size of > your threads. This is easy. > > Next, carefully review your code, specially those > parts, that write to allocated memory. The malloc > routines in the debug version (NUTDEBUG) offer > some additional protection and may help to locate > the problem. > > If two threads are modifying multibyte values, > make sure, that the modification is atomic. > > Most likely the problem is _not_ caused by too less > heap space. > > Harald > > > At 09:56 02.02.2004 -0500, you wrote: > >Hi, All. > >I have such a problem: > >I use two network oriented threads. > >Main thread periodically sends data through Inet using POST method of http > >protocol. Having sent the next potion of data, it obtains something as > >server reply and parses it as server command. > >Another thread, which I call DirectTCP, opens another socket and accepts > >data from port 23 - telnet like this: > >NutTcpAccept(dirsock, 23). > >It is supposed to be used for immediate incoming commands from the server. > >Actually, it works but sometimes it hangs up and the box is being reloaded > >by watchdog. I tried to investigate the situation and found that the > >'tdp->td_memory' of the main thread after some time becomes not equal to > >DEADBEEF, which is interpreted as "CORRUPT" in one of the examples. I tried > >to free as much heap as possible and now I have almost 16K heap available, > >but I have not achieved stable work still. > >Maybe I have to upgrade the system? Judging from version.c I use 3.3.0.1. > >now. Please, advise. > >Thanks, > >Alexander Baranov > > > >_______________________________________________ > >En-Nut-Discussion mailing list > >En-Nut-Discussion at egnite.de > >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From harald.kipp at egnite.de Tue Feb 3 21:46:30 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 03 Feb 2004 21:46:30 +0100 Subject: [En-Nut-Discussion] Nut/OS and ImageCraft Message-ID: <5.1.1.6.0.20040203214453.01b9fb78@egnite.de> Using ImageCraft C at http://www.ethernut.de/en/iccavr/index.html had been partly updated. This was really old stuff. Harald From Baranov at intech21.com Tue Feb 3 23:28:13 2004 From: Baranov at intech21.com (Alexander Baranov) Date: Tue, 3 Feb 2004 17:28:13 -0500 Subject: [En-Nut-Discussion] main thread stack size References: <5.1.1.6.0.20040203170408.0321e1a0@egnite.de> Message-ID: <000901c3eaa5$02cf2860$1101000a@Alex> Harald, thanks once more. I found the place and increased the stack size. Now it seems to work. Alex ----- Original Message ----- From: "Harald Kipp" To: "Ethernut User Chat (English)" Sent: Tuesday, February 03, 2004 11:31 AM Subject: Re: [En-Nut-Discussion] PPP fixes > Hi Michel, > > > > > As promised, here are my fixes for PPP. Sorry it took so long :-) > > No problem, but I fear it's too late for 3.4.1. We already > spend two days on the tests and just finished the Windows > installation. Linux installation is being build right now. > > Your patches make sense to me, but I needed some time to > get into the code again. Sigh, this PPP stuff is really > weird. > > I'll add your changes to HEAD and, after some additional > connection tests, to 3.4.2. > > Many thanks for the good job, > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From damian at commtech.com.au Wed Feb 4 01:57:52 2004 From: damian at commtech.com.au (Damian Slee) Date: Wed, 4 Feb 2004 08:57:52 +0800 Subject: [En-Nut-Discussion] Supporting Other Target Platforms Message-ID: About US$15.43 at www.digikey.com for 100 price break. About $2-$4 more than the Mega128. That's about 20% more cost for a lot more powerfull uC. Caught the eye of our electronics engineer some month back. Sounded good to me. In Australia; Budgetary Info AT91FR40162-CI Price: USD$17.50 MOQ 83 pcs rounded up to nearest packsize. Pack Qty: TBC Lead time 10-12 wks ARO -----Original Message----- From: Harald Kipp [mailto:harald.kipp at egnite.de] Sent: Tuesday, 3 February 2004 9:21 PM To: Ethernut User Chat (English) Subject: RE: [En-Nut-Discussion] Supporting Other Target Platforms Damian, At 20:59 03.02.2004 +0800, you wrote: >The AT91FR40162 appears to be a copy of the AT92R40008 but with the 2M >flash on chip. BGA package. Makes for a really really small design. As far as I know this is a two die chip. Might be expensive. > >However the Samsung one mentioned earlier with onboard LAN I have seen >in the Linksys access points. But external flash and ram. Be aware that most of the onboard LANs are MAC only, no PHY. Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From ralph.mason at telogis.com Wed Feb 4 17:14:55 2004 From: ralph.mason at telogis.com (Ralph Mason) Date: Thu, 05 Feb 2004 05:14:55 +1300 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <5.1.1.6.0.20040203141458.03303cf8@egnite.de> References: <5.1.1.6.0.20040203141458.03303cf8@egnite.de> Message-ID: <40211A7F.3090000@telogis.com> I like the look of the OKI chips http://www.okisemi.com/jp/english/ml674k.htm I was quoted $8.86US on the ML67Q4002TC in lots of 60 and $10.45 US on the ML67Q4003TC http://www.okisemi.com/jp/english/arm-strt.htm. There is also a step up from there to a faster chip in the same package. They read very much like a big AVR, (but cost less than one). The look like quite a natural progression and fit on an AVR board. Ralph > Damian, > > At 20:59 03.02.2004 +0800, you wrote: > >> The AT91FR40162 appears to be a copy of the AT92R40008 but with the >> 2M flash on chip. BGA package. Makes for a really really small design. > > > As far as I know this is a two die chip. Might > be expensive. > > >> >> However the Samsung one mentioned earlier with onboard LAN I have >> seen in the Linksys access points. But external flash and ram. > > > Be aware that most of the onboard LANs are MAC > only, no PHY. > > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > -- NOTICE: This message (including any attachments) contains CONFIDENTIAL INFORMATION intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. From tgeffers at web.de Wed Feb 4 18:25:45 2004 From: tgeffers at web.de (Geffers, Thorsten) Date: Wed, 4 Feb 2004 18:25:45 +0100 Subject: [En-Nut-Discussion] General PPP Question Message-ID: <000001c3eb43$ed905060$9699a8c0@Notebook> Hi @all! Maybe this isn't exactly an ethernut question, but I think (and hope) someone can help me! I have a PPP implementation that works well with a German ISP. After the PAP Ack the ISP sends an IPCP Request and everything works fine. Then I tested it via GPRS and an GPRS provider. This provider seems to wait for the client to send an IPCP Request. Does everybody now if it's right that some ISP send an IPCP Request and others wait for the client to do so?? And if it's true, how can software handle it? Because if both sides send requests, it seems that there will be no end with the IPCP phase. Thank you for your help!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From c.a.m at blueyonder.co.uk Wed Feb 4 19:11:05 2004 From: c.a.m at blueyonder.co.uk (c.a.m at blueyonder.co.uk) Date: Wed, 04 Feb 2004 18:11:05 +0000 Subject: [En-Nut-Discussion] General PPP Question In-Reply-To: <000001c3eb43$ed905060$9699a8c0@Notebook> References: <000001c3eb43$ed905060$9699a8c0@Notebook> Message-ID: On Wed, 4 Feb 2004 18:25:45 +0100, you wrote: >Hi @all! > >Maybe this isn't exactly an ethernut question, but I think (and hope) >someone can help me! > >I have a PPP implementation that works well with a German ISP. After the >PAP Ack the ISP >sends an IPCP Request and everything works fine. > >Then I tested it via GPRS and an GPRS provider. This provider seems to >wait for the client >to send an IPCP Request. > >Does everybody now if it's right that some ISP send an IPCP Request and >others wait for the >client to do so?? And if it's true, how can software handle it? Because >if both sides send requests, >it seems that there will be no end with the IPCP phase. Well, the way I see it, is that you send your request no matter what (after both sides have accepted each others LCP options), with your ip entries set to 0.0.0.0 (unless you are using fixed ip's). I spent quite some time writing a complete PPP routine etc (it's on the AVR freaks site in the projects area - ppp.zip). So far, it works flawlessly on a windows ppp server, BY and NTL ISP's via dial up modem, and on the vodaphone and orange networks via gprs here in the UK. As soon as the LCP options are done with, I send an immediate IPCP request with the 3 ip's set to 0.0.0.0 ... whether they send their IPCP first makes no odd's really, you just rej the compression option to start with (if you don't use compression), and ack the ip option they send (the next time they send their request). As with the LCP options, the negotiations are separate (each end), and it doesn't matter who sends the first request. Lexxy From dferbas at dfsoft.cz Thu Feb 5 00:08:57 2004 From: dferbas at dfsoft.cz (Dusan Ferbas) Date: Thu, 05 Feb 2004 00:08:57 +0100 Subject: [En-Nut-Discussion] General PPP Question In-Reply-To: <20040204172800.17FC22F42A7@p15095813.pureserver.info> References: <20040204172800.17FC22F42A7@p15095813.pureserver.info> Message-ID: <6.0.1.1.2.20040205000024.01af5780@pop3.servery.cz> Hi Geffers, as far as I know both sides should send IPCP requests because each side has to be assigned with an IP address. IP address can be 0.0.0.0 then it is a request for assignment from the other side. Nonzero address can be REJected or NAKed to negotiate. It can happen that both sides want to force their idea of IP address. In such a case PPP negotiation always fails. LCP negotiation can be initiated from one side. This is not true for IPCP. I assume that if you are connecting to an ISP you should send IPCP conf. req. and you should send it with 0.0.0.0, DNS1,2 0.0.0.0 options. >Date: Wed, 4 Feb 2004 18:25:45 +0100 >From: "Geffers, Thorsten" >Subject: [En-Nut-Discussion] General PPP Question > >Hi @all! > >Maybe this isn't exactly an ethernut question, but I think (and hope) >someone can help me! > >I have a PPP implementation that works well with a German ISP. After the >PAP Ack the ISP >sends an IPCP Request and everything works fine. > >Then I tested it via GPRS and an GPRS provider. This provider seems to >wait for the client >to send an IPCP Request. > >Does everybody now if it's right that some ISP send an IPCP Request and >others wait for the >client to do so?? And if it's true, how can software handle it? Because >if both sides send requests, >it seems that there will be no end with the IPCP phase. > Dusan From damian at commtech.com.au Thu Feb 5 03:07:58 2004 From: damian at commtech.com.au (Damian Slee) Date: Thu, 5 Feb 2004 10:07:58 +0800 Subject: [En-Nut-Discussion] Supporting Other Target Platforms Message-ID: Looks alright Ralph. Gets rid of the external RAM in the mega128 and a bit more code space. Do you used the ARM SDT C compiler that have listed there? I couldn't see anywhere to download it. Or GCC http://www.okisemi.com/jp/english/armsdt.htm If you like more ram/flash on chip, I still think the Atmel ones the way to go. -----Original Message----- From: Ralph Mason [mailto:ralph.mason at telogis.com] Sent: Thursday, 5 February 2004 12:15 AM To: Ethernut User Chat (English) Subject: Re: [En-Nut-Discussion] Supporting Other Target Platforms I like the look of the OKI chips http://www.okisemi.com/jp/english/ml674k.htm I was quoted $8.86US on the ML67Q4002TC in lots of 60 and $10.45 US on the ML67Q4003TC http://www.okisemi.com/jp/english/arm-strt.htm. There is also a step up from there to a faster chip in the same package. They read very much like a big AVR, (but cost less than one). The look like quite a natural progression and fit on an AVR board. Ralph > Damian, > > At 20:59 03.02.2004 +0800, you wrote: > >> The AT91FR40162 appears to be a copy of the AT92R40008 but with the >> 2M flash on chip. BGA package. Makes for a really really small design. > > > As far as I know this is a two die chip. Might be expensive. > > >> >> However the Samsung one mentioned earlier with onboard LAN I have >> seen in the Linksys access points. But external flash and ram. > > > Be aware that most of the onboard LANs are MAC > only, no PHY. > > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > -- NOTICE: This message (including any attachments) contains CONFIDENTIAL INFORMATION intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From ngbmoreau at yahoo.com.au Thu Feb 5 06:00:53 2004 From: ngbmoreau at yahoo.com.au (NGB) Date: Thu, 5 Feb 2004 16:00:53 +1100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: References: Message-ID: <1075957253.4021ce05e8138@tiger.enttec> I'd be a bit worried about OKI chips, for the people who are in a supplier black hole like Australia. It's very hard to get our hands on these chips. Atmel on the other hand is readily availabe, support is easy to get too, If this is to become Ethernut 3, I'd strongly recommend staying with a mainstream / low volume manufacturer my 2 cents Nic Quoting Damian Slee : > Looks alright Ralph. Gets rid of the external RAM in the mega128 and a > bit more code space. > Do you used the ARM SDT C compiler that have listed there? I couldn't > see anywhere to download it. Or GCC > http://www.okisemi.com/jp/english/armsdt.htm > > > If you like more ram/flash on chip, I still think the Atmel ones the way > to go. > ------------------------------------------------- From damian at commtech.com.au Thu Feb 5 06:28:01 2004 From: damian at commtech.com.au (Damian Slee) Date: Thu, 5 Feb 2004 13:28:01 +0800 Subject: [En-Nut-Discussion] Supporting Other Target Platforms Message-ID: Have to agree with that. We couldn't get any mega32's here. Got them through our US office in a couple of weeks. -----Original Message----- From: NGB [mailto:ngbmoreau at yahoo.com.au] Sent: Thursday, 5 February 2004 1:01 PM To: Ethernut User Chat (English) Subject: RE: [En-Nut-Discussion] Supporting Other Target Platforms I'd be a bit worried about OKI chips, for the people who are in a supplier black hole like Australia. It's very hard to get our hands on these chips. Atmel on the other hand is readily availabe, support is easy to get too, If this is to become Ethernut 3, I'd strongly recommend staying with a mainstream / low volume manufacturer my 2 cents Nic Quoting Damian Slee : > Looks alright Ralph. Gets rid of the external RAM in the mega128 and a > bit more code space. > Do you used the ARM SDT C compiler that have listed there? I couldn't > see anywhere to download it. Or GCC > http://www.okisemi.com/jp/english/armsdt.htm > > > If you like more ram/flash on chip, I still think the Atmel ones the > way to go. > ------------------------------------------------- _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From erik at lins.de Thu Feb 5 08:18:36 2004 From: erik at lins.de (Erik Lins) Date: Thu, 5 Feb 2004 08:18:36 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms Message-ID: <200402050718.i157IaK03152@web08.manitu.net> Hi, are there some other people who would be interested in a ColdFire port of Nut/OS? The MCF5282 is a cute part (64k SRAM, 512k Flash, lots of peripherals like UART,SPI,I2C,CAN,ADC and Ethernet MAC, external Bus available). Nut/OS would run without external memory, the only thing needed would be the ethernet Phy. I started setting up a suitable GNU toolchain on Cygwin and would provide binaries for download on my homepage on request. I also started a hardware project based on that ColdFire, which could be a basis for porting. Alternatively I would use my ColdFire Evalboard (http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D4888% 2526CCD%253DUSA%2526SID%253D4746%2526DID%253DDF2%2526SRT%253D1%2526LID% 253D0%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html). Who the hell needs such ugly URLs??? Cheers, ER!K --- LINS Technologies http://www.lins.de From ralph.mason at telogis.com Thu Feb 5 08:47:55 2004 From: ralph.mason at telogis.com (Ralph Mason) Date: Thu, 05 Feb 2004 20:47:55 +1300 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: References: Message-ID: <4021F52B.2000808@telogis.com> Damian Slee wrote: >Looks alright Ralph. Gets rid of the external RAM in the mega128 and a >bit more code space. >Do you used the ARM SDT C compiler that have listed there? I couldn't >see anywhere to download it. Or GCC >http://www.okisemi.com/jp/english/armsdt.htm > > >If you like more ram/flash on chip, I still think the Atmel ones the way >to go. > > > An 8mb dram is only a couple of dollars, there is no way you will approach 8mb ram and 512kb flash for $12 from atmel. For another $3 you can add a couple mb more flash. There are 4 chip selects so it's nice and easy to connect a few items to the bus. I think I will use GCC with it ( I am planing on doing something with it in the milddle of the year). Ralph From harald.kipp at egnite.de Thu Feb 5 11:26:55 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Thu, 05 Feb 2004 11:26:55 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <4021F52B.2000808@telogis.com> References: Message-ID: <5.1.1.6.0.20040205105833.031cf3e0@egnite.de> Ralph, >An 8mb dram is only a couple of dollars, there is no way you will approach >8mb ram and 512kb flash for $12 from atmel. For another $3 you can add a >couple mb more flash. There are 4 chip selects so it's nice and easy to >connect a few items to the bus. I'm afraid, that it's not that simple. As far as I understood, the low cost thumbs are running with 32 bit access in internal memory only. Having Nut/OS and the application in on-chip RAM is an advantage. Another thing is, that total cost is also based on chip count and PCB size. On the other hand, external flash gives more flexibility. It may contain the image _plus_ a file system. Harald From ngbmoreau at yahoo.com.au Thu Feb 5 11:31:01 2004 From: ngbmoreau at yahoo.com.au (NGB) Date: Thu, 5 Feb 2004 21:31:01 +1100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <200402050718.i157IaK03152@web08.manitu.net> References: <200402050718.i157IaK03152@web08.manitu.net> Message-ID: <1075977061.40221b657625d@localhost:2000> Watch out, this will start a processor war :-) I know the motorola cpus have some great features but: 1-AVR's are quite close to ARM cores 2-You will get a lot more out of an ARM port because of the number of processors available from different vendors. 3-You can easily upgrade to better cores eg: ARM9 I hope this makes sense. Nic Quoting Erik Lins : > Hi, > > are there some other people who would be interested in a ColdFire port > of Nut/OS? The MCF5282 is a cute part (64k SRAM, 512k Flash, lots of > peripherals like UART,SPI,I2C,CAN,ADC and Ethernet MAC, external Bus > available). Nut/OS would run without external memory, the only thing > needed would be the ethernet Phy. ------------------------------------------------- From harald.kipp at egnite.de Thu Feb 5 12:20:58 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Thu, 05 Feb 2004 12:20:58 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <1075957253.4021ce05e8138@tiger.enttec> References: Message-ID: <5.1.1.6.0.20040205112922.031d2b68@egnite.de> Hi Nic and others, At 16:00 05.02.2004 +1100, you wrote: >I'd be a bit worried about OKI chips, for the people who are in a supplier >black >hole like Australia. It's very hard to get our hands on these chips. >Atmel on the other hand is readily availabe, support is easy to get too, >If this is to become Ethernut 3, I'd strongly recommend staying with a >mainstream / low volume manufacturer > >my 2 cents > >Nic I'll take the chance to answer in a more general way. egnite will not be able to design and produce Ethernut hardware for all CPU flavors. We hope, that more hardware vendors will offer low level Ethernet enabled boards and support Nut/OS. That strategy may look stupid to our revenue oriented business, but only on the first look. I strongly believe, that if more people become involved, our company will benefit in the end. Charon II from http://www.hw.cz/ is a good alternative and we will put more effort into it's support. Hopefully Jan can get its production quantities up. http://www.lins.de/ has started with a Coldfire design. I wish he will get more response from this list than last time. Nevertheless, new hardware is coming from us. Mid of this month we will have the first series of Ethernut 2.zip, an ATmega128 - LAN91C111 - 32 kByte RAM module with PLCC-84 form factor. After this we will immediately start with an Ethernut 3 reference design, based on ARM. Like with Ethernut 2, we will publish early layouts and will be open to discuss them. This mailing list previously "forced" us, to put a CPLD on Ethernut 2, which was a very good decision. And I agree with you, that it is most important to use easy to get parts for Ethernut 3 to attract potential users. OKI is indeed a bit difficult, as they mainly produce these chips for their own use. Last, we consider to change the PCB format to something more flexibel. Don't panic, Ethernut 1/2 will be kept unchanged :-) Harald From zodianet at wanadoo.fr Thu Feb 5 12:42:44 2004 From: zodianet at wanadoo.fr (Zodianet) Date: Thu, 5 Feb 2004 12:42:44 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <5.1.1.6.0.20040205105833.031cf3e0@egnite.de> Message-ID: <20040205114446.54C43400917@mwinf0301.wanadoo.fr> I am not sure that Nut/OS needs a great "CPU upsizing" today but it needs to become first more reliable before migrate! Other bigger OS are in place and could be a better choice for bigger CPUs to fill quickly 512K of Flash ;-). Jean Pierre -----Message d'origine----- De : en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de] De la part de Harald Kipp Envoy? : jeudi 5 f?vrier 2004 11:27 ? : Ethernut User Chat (English) Objet : Re: [En-Nut-Discussion] Supporting Other Target Platforms Ralph, >An 8mb dram is only a couple of dollars, there is no way you will >approach 8mb ram and 512kb flash for $12 from atmel. For another $3 >you can add a couple mb more flash. There are 4 chip selects so it's >nice and easy to connect a few items to the bus. I'm afraid, that it's not that simple. As far as I understood, the low cost thumbs are running with 32 bit access in internal memory only. Having Nut/OS and the application in on-chip RAM is an advantage. Another thing is, that total cost is also based on chip count and PCB size. On the other hand, external flash gives more flexibility. It may contain the image _plus_ a file system. Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From ralph.mason at telogis.com Fri Feb 6 12:59:58 2004 From: ralph.mason at telogis.com (Ralph Mason) Date: Sat, 07 Feb 2004 00:59:58 +1300 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <5.1.1.6.0.20040205105833.031cf3e0@egnite.de> References: <5.1.1.6.0.20040205105833.031cf3e0@egnite.de> Message-ID: <402381BE.4070605@telogis.com> Harald Kipp wrote >> An 8mb dram is only a couple of dollars, there is no way you will >> approach 8mb ram and 512kb flash for $12 from atmel. For another $3 >> you can add a couple mb more flash. There are 4 chip selects so >> it's nice and easy to connect a few items to the bus. > > > I'm afraid, that it's not that simple. As far as I > understood, the low cost thumbs are running with > 32 bit access in internal memory only. Having Nut/OS > and the application in on-chip RAM is an advantage. But running thumb from 16 bit memory is optimal. It's all a question of what the goal is. To me it's more performance ( to allow simpler programing) with no more cost. > > Another thing is, that total cost is also based on chip > count and PCB size. And this one is nice, dram uses very few lines, the chip is in a 2cm X 2cm qfp package. Sounds like a 2 layer board to me. Clearly less than a atmega, a cpld and sram. > On the other hand, external flash gives more flexibility. > It may contain the image _plus_ a file system. Nand flash is always cheaper for a file system (and I have a nut compatible nand flash file system almost ready to release!) I guess at the end of the day, what is NutOS trying to be? Is it a new ecos in the making? Does it (Do we?) support process loading? What about AVR's - does it get so heavy as to leave them behind? Interesting article in Linux world this month - about open source trying to compete with itself (http://www.linuxworld.com/magazine/?issueid=352&de=1) Ralph From 021243 at student.hit.no Fri Feb 6 14:12:42 2004 From: 021243 at student.hit.no (Sigurd Kleppan) Date: Fri, 06 Feb 2004 14:12:42 +0100 Subject: [En-Nut-Discussion] Pin I/O Message-ID: I know how to set output pins. outp(0xff,PORTA); In this commando you have to set all 8 pins in one operation. I only want to set one pin without setting the other 7 pins. Can i do this with following commandos? If this is possible, how to i find the unique adress of each pin? By the way, do NUT/OS have some commando to send serial word through the I/O ports? This is a code i have found used by a another microcontroller. The code is used to get a temperature from DS1620. //Setting adress of the pins sbit RST = 0xA2; /* DS1620 reset line */ sbit CLK = 0xA3; /* DS1620 clock line */ sbit DQ = 0xA4; /* DS1620 data line void Put1620byte(unsigned char m) { unsigned char k,b=1; RST=1; for (k=0; k<8; k++) { CLK=0; DQ = (m & b); /* Send bit to 1620 */ CLK=1; b=(b<<1); /* Setup to send next bit */ } return; } unsigned char Get1620byte( void ) { unsigned char j,k=0,b=1; k=0; b=1; for (j=0; j<8; j++) { CLK=0; if (DQ) k|=b; /* Read bit and or if = 1 */ CLK=1; b=(b<<1); /* Setup for next read and or */ } return k; } void main(){ RST=1; Put1620byte(0xAA); /* read temp command */ temp_and_half_bit = Get1620byte(); /* read 1st byte of temp */ sign_bit = Get1620byte(); /* read 2nd byte of temp */ RST=0; } From bbuenaobra at nip.upd.edu.ph Sat Feb 7 11:32:18 2004 From: bbuenaobra at nip.upd.edu.ph (Berns J. Buenaobra) Date: Sat, 7 Feb 2004 02:32:18 -0800 Subject: [En-Nut-Discussion] How to echo to CRT external EEPROM R/W Message-ID: <000101c3ed65$ad0dabe0$3a65a8c0@instru.nip.upd.edu.ph> Hello all: I know this is too much for graduate student to ask but I'm desperate to have my lab project go through the end objective. I need to somehow see in my computer screen (CRT) when I am able to write to EEPROM and/or read back from the computer screen via hyperlink on a HTTP webserver page to a CGI what I have just written to it. Any ideas? Where and how should I connect my Ethernut board to do just exactly this? What can be the building blocks needed from the supplied examples? Thank you for your time. 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 ************************************ From ceba at vabo.cz Sat Feb 7 12:22:32 2004 From: ceba at vabo.cz (Pavel Celeda) Date: 07 Feb 2004 12:22:32 +0100 Subject: [En-Nut-Discussion] Missing lib directory in 3.4.1rc1 Message-ID: <1076152951.2325.79.camel@hw.vabo.cz> Hi, today I checked out Nut release candidate 3.4.1rc1 from CVS cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/ethernut co -r nut-3_4-release nut and there is no lib/... directory available. with best regards Pavel From ethernut at objenv.com Sun Feb 8 01:42:38 2004 From: ethernut at objenv.com (Rich Wellner) Date: Sat, 07 Feb 2004 18:42:38 -0600 Subject: [En-Nut-Discussion] NutUdpSendTo problem In-Reply-To: <000001c3b9b3$cf7ce820$1601a8c0@p3> ("Lars Andersson"'s message of "Wed, 3 Dec 2003 16:40:41 +0100") References: <000001c3b9b3$cf7ce820$1601a8c0@p3> Message-ID: <87ptcq7669.fsf@objenv.com> I wonder if you guys can spot me doing something obviously wrong here. I call NutUdpSendTo and always get a -1 return. I see from the mail list archives that there was a buffer handling problem in NutUdpSendTo in the past, but I've checked my source and not only does this problem seem unrelated, but I have the patch for the buffer handling issue. If I change the dest ip to 207.252.251.233 and run ethereal on the dest node then I get 0 returns from NutUdpSendTo and the activity light on the ethernut lights up, but the packet is never seen at the destination. output: ip: 207.252.251.238 netmask: 255.255.255.248 gateway: 207.252.251.233 dest ip: 216.127.80.16 return: -1 return: -1 return: -1 Source: int main(void) { u_long baud = 115200; u_char i; u_long dest_addr; UDPSOCKET *udpsock; /* * Initialize the uart device. */ NutRegisterDevice(&devDebug0, 0, 0); freopen("uart0", "w", stdout); _ioctl(_fileno(stdout), UART_SETSPEED, &baud); NutSleep(200); printf("\n\nNut/OS %s HTTP Daemon...\n", NutVersionString()); #ifdef NUTDEBUG NutTraceTcp(stdout, 0); NutTraceOs(stdout, 0); NutTraceHeap(stdout, 0); NutTracePPP(stdout, 0); #endif /* * Register Ethernet controller. */ //if(NutRegisterDevice(&devSmsc111, 0, 0)) if (NutRegisterDevice(&devEth0, 0x8300, 5)) puts("Registering device failed"); /* * LAN configuration using EEPROM values or DHCP/ARP method. * If it fails, use fixed values. */ if (NutDhcpIfConfig("eth0", 0, 60000)) { u_char mac[] = { MYMAC }; u_long ip_addr = inet_addr(MYIP); u_long ip_mask = inet_addr(MYMASK); puts("EEPROM/DHCP/ARP config failed"); NutNetIfConfig("eth0", mac, ip_addr, ip_mask); } printf("ip: %s\n", inet_ntoa(confnet.cdn_ip_addr)); printf("netmask: %s\n", inet_ntoa(confnet.cdn_ip_mask)); printf("gateway: %s\n", inet_ntoa(confnet.cdn_gateway)); udpsock = NutUdpCreateSocket(0); dest_addr = inet_addr("216.127.80.16"); printf("dest ip: %s\n", inet_ntoa(dest_addr)); /* * We could do something useful here, like serving a watchdog. */ NutThreadSetPriority(254); for (;;) { printf("return: %d\n", NutUdpSendTo(udpsock, dest_addr, 2526, "test", 4)); NutSleep(1000); } } From fischermi at t-online.de Sun Feb 8 11:17:34 2004 From: fischermi at t-online.de (Michael Fischer) Date: Sun, 8 Feb 2004 11:17:34 +0100 Subject: [En-Nut-Discussion] Ethernut CF (WLAN) Interface Message-ID: Hello, I think you have read the last thread about the Ethernut IDE/CF Interface. The problem was (is) that the Netgear MA401 is using the WAIT signal. Therefore I have now a new prototype with a bigger Xilinx. All the signals are pass-through the CPLD. This has the effect that I can use it as a level shifter for 3.3 and 5.0 voltage. But the "problem" with the WAIT still exist. Now I emulate the bus access. That mean the CPLD have several register and use an address range of 4 bytes. To make a write access to the MA401 you must use the follwing source: /************************************************************/ /* WriteXXX */ /************************************************************/ static void WriteXXX (WORD wAddress, WORD wData, MEMORY_TYPE eIO) { /* * set ADDRESS */ ADDRESS_LOW_REG = LOBYTE(wAddress); ADDRESS_HIGH_REG = HIBYTE(wAddress); /* * set DATA */ DATA_LOW_REG = LOBYTE(wData); DATA_HIGH_REG = HIBYTE(wData); /* * set CE1, CE2 */ CTRL_REG = (CTRL_CE1 | CTRL_CE2 | CTRL_OE | CTRL_WE | CTRL_IORD | CTRL_IOWR | CTRL_DATA_OUT); /* * set WR/IOWR */ if (eIO == TYPE_MEM) { CTRL_REG = (CTRL_CE1 | CTRL_CE2 | CTRL_OE | CTRL_IORD | CTRL_IOWR | CTRL_DATA_OUT); } else { CTRL_REG = (CTRL_CE1 | CTRL_CE2 | CTRL_OE | CTRL_WE | CTRL_IORD | CTRL_DATA_OUT); } /* * check the WAIT signal */ //Do some code here /* * remove WR/IOWR */ CTRL_REG = (CTRL_CE1 | CTRL_CE2 | CTRL_OE | CTRL_WE | CTRL_IORD | CTRL_IOWR | CTRL_DATA_OUT); /* * remove CE1, CE2 */ CTRL_REG = ( CTRL_OE | CTRL_WE | CTRL_IORD | CTRL_IOWR); } But this takes to long, up to 1,5us for an access. How can we solve this problem now? 1. Use the old way, direct mem/io access to the card. But use the function XDIV of the CPU. Divide the clock down to 3Mhz and hope the card get no problem. This was my first try with the first prototype. 2. Build a state machine in the CPLD. Which handle the access. I can imagine the following procedure: The CF card is a 16bit card, therefore we need to access, like the same as the IDE interface. Write the high byte at the odd address, and after this the low byte at the even address. The CPLD latch the address and the data. The last write at the even address start the state machine in the CPLD. Now the CPLD will do the rest. To check if this access is ready, there must exist a ctrl register in the CPLD. We can read this ctrl-reg and if the access is ready, a bit it set. I hope this is faster than 1,5us. Now some words about the source: I use here the source from FreeBSD, with the 1,5us way. I can access the MA401 (It is the 5V PCMCIA card). I hope that in the next weeks it is possible to receive a packet over the air. Who can help to design the CPLD? It should be a Xilinx CPLD, because the software is free. And I use here the Xilinx WebPack 6.1. Best regards, Michael From harald.kipp at egnite.de Sun Feb 8 22:00:53 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Sun, 08 Feb 2004 22:00:53 +0100 Subject: [En-Nut-Discussion] test, please ignore Message-ID: <5.1.1.6.0.20040208220039.0322d3f8@egnite.de> From Douglas.Pearless at pearless.co.nz Sun Feb 8 22:25:15 2004 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Mon, 09 Feb 2004 10:25:15 +1300 Subject: [En-Nut-Discussion] Driving a daugther board from the EtherNut 2 In-Reply-To: <5.1.1.6.0.20040205112922.031d2b68@egnite.de> Message-ID: <20040208211926.E0693ADFE3@smtp-3.paradise.net.nz> Hi people, I am redesigning an EtherNut 1.3 daughter board to work with the newer EtherNut 2. The daughter board can draw at a peak, 5v up to 1.7 amps. In the past, the daughter board has a 5v 3A power supply that supplies the 5v to the EtherNut 1.3 (we remove the 5v regulator from the EtherNut) via the expansion header. Is it possible to upgrade the LM1086(1.5A) to a LM1085 (3A) or a LM1084(5A)? What else would need to change (F1 to 3A or 5A)? Would this work with the current board design (track width, vias etc)? I guess this will become more of an issue as more and more daughter / expansion boards are developed! The other alternative is to put a LM1084 on the daughter board, and removing the LM1086 from the EtherNut, which would not be my preference. Cheers Douglas --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.580 / Virus Database: 367 - Release Date: 6/02/2004 From Douglas.Pearless at pearless.co.nz Sun Feb 8 23:20:04 2004 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Mon, 09 Feb 2004 11:20:04 +1300 Subject: [En-Nut-Discussion] Complete newbie... In-Reply-To: <5.1.1.6.0.20030817111617.01a8d880@egnite.de> Message-ID: <20040208221415.C7D709E277@smtp-2.paradise.net.nz> As an aside, I was looking for information on the memory mapping of the EtherNut 2. This seems to be the only references I could find to the memory mapping in the mailing list and website. I assume that this is still current, and if I use 0xFE00-0xFEFF inclusive for a daughter board I have designed (it can be jumpered into any block as I decode A8-A15) that this will not cause a conflict? 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: Sunday, 17 August 2003 9:33 p.m. To: en-nut-discussion at egnite.de Subject: Re: [En-Nut-Discussion] Complete newbie... Radek, There's no limitation using any memory addresses from 0x8000 to 0x82FF and 0x8320 to 0xFFFF. May be there's some kind of address decoder timing problem, so that 0xE000 gets unintendently selected. How about adding delay cycles? More infos are given in the ATmega128 data sheet. Sure, there may be a bug in the software, but unlikely. Ethernut 2 uses all addresses upto 0xBFFF, the LAN91C111 is located at 0xC000 and the bank select register occupies 0xFF00 upto 0xFFFF. It uses the same software, just the NIC driver has been replaced. 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.510 / Virus Database: 307 - Release Date: 14/08/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.580 / Virus Database: 367 - Release Date: 6/02/2004 From Douglas.Pearless at pearless.co.nz Sun Feb 8 23:47:29 2004 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Mon, 09 Feb 2004 11:47:29 +1300 Subject: [En-Nut-Discussion] Ethernut 2 Message-ID: <20040208224141.493DC9E288@smtp-2.paradise.net.nz> Hi People, I am redesigning an EtherNut 1.3 daughter board (Quad UARTS, RS485/232/IrDA/Flash RAM, RTC clock/calendar, etc etc) to work with the newer EtherNut 2. As I am not sure my previous posting got through, I?d like to summarise my questions about the EtherNut 2: PE6 (INT6) is NOT used and can by used by my own design. Only RESET\ and not RESET goes to the expansion header (any plans to change this???) I can use 0xFE00 ? 0xFEFF to memory map my own design (if not, what ranges are available?). And lastly, the daughter board can draw at a peak, 5v up to 1.7 amps. In the past, the daughter board has a 5v 3A power supply that supplies the 5v to the EtherNut 1.3 via the expansion header (we remove the 5v regulator from the EtherNut). Is it possible to upgrade the LM1086(1.5A) to a LM1085 (3A) or a LM1084(5A)? What else would need to change (F1 to 3A or 5A)? Would this work with the current board design (track width, vias etc)? I guess this will become more of an issue as more and more daughter / expansion boards are developed! The other alternative is to put a LM1084 on the daughter board, and removing the LM1086 from the EtherNut, which would not be my preference. Cheers Douglas --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.580 / Virus Database: 367 - Release Date: 6/02/2004 -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at lins.de Mon Feb 9 10:03:43 2004 From: erik at lins.de (Erik Lins) Date: Mon, 9 Feb 2004 10:03:43 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms Message-ID: <200402090903.i1993hV06165@web08.manitu.net> Dear Nic, > Watch out, this will start a processor war :-) uuh, I don't hope so! Everybody has it's favorate processor architecture and the reasons range from real technical issues over "we never used anything else" and end up to religious and fanatic reasons. I don't want to convince andbody to use ColdFire instead of ARM or whatever. > I know the motorola cpus have some great features but: > 1-AVR's are quite close to ARM cores That's correct and it might be an advantage during porting Nut/OS to the new architecture, but the advantage gets smaller when you program mostly in C/C++ and diminishes further when porting is done and you write native applications for the new CPU. > 2-You will get a lot more out of an ARM port because of the number of > processors available from different vendors. Well, that's a more "global" point of view, it might be true, that - well - "mankind" gets more out of an ARM port, but I have a certain demand for a ColdFire port, so in the near future _I_ will get more out of a ColdFire port. And since Harald takes care of an ARM port, both me and mankind should be satisfied in the end. ;-) The raw number of core implementations is not necessarily an indication for the quality of that core (I guess 8051 is on of the most often implemented cores and also one of the worst architectures humans ever invented, and also Intels x86 architecture is clearly deeply sub- optimal), but more an indication for the quality of some companies marketing division. > 3-You can easily upgrade to better cores eg: ARM9 Motorola (and to some extend IBM) offers ColdFire cores in various performance ranges (V2 core currently up to 125MHz, V4 core up to 316MHz) and the PowerPC based controllers (PowerQUICC network processors and MPCxxx microcontrollers) are some kind of elemental upgrade path ranging up to several hundred MHz. As my english teacher often mentioned: "Variety is the salt of life", so I think we should try to make Nut/OS available on several CPU architectures and I'm convinced that all ports will benefit from the work and experiences collected in certain ports, expecially non- mainstream ports in the end. Cheers, ER!K --- LINS Technologies http://www.lins.de From harald.kipp at egnite.de Mon Feb 9 11:06:25 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 09 Feb 2004 11:06:25 +0100 Subject: [En-Nut-Discussion] test Message-ID: <5.1.1.6.0.20040209110616.01c35488@egnite.de> test From Oliver.Schulz at bong.de Mon Feb 9 11:42:44 2004 From: Oliver.Schulz at bong.de (Oliver Schulz) Date: Mon, 9 Feb 2004 11:42:44 +0100 Subject: AW: [En-Nut-Discussion] NutUdpSendTo problem Message-ID: Hi Rich, > the patch for the buffer handling issue. If I change the dest ip to > 207.252.251.233 and run ethereal on the dest node then I get > 0 returns from So if use use an ip address of your LAN, the function returns 0. Looks like a routing problem. I discovered last weekend a small hidden bug in network interface configuring functions. If no DHCP is used (that is, if ethernut's ip address is set to a valid address during basemon), the gateway ip address is not added as default route, although it's properly configured in confnet struct. Rich, can you tell me, if you use DHCP for ethernut? Anyway, this evening I try to commit a bufgix for that in nut-3_4-release branch. Cheers, Oliver. From malte_rennert at web.de Mon Feb 9 13:59:54 2004 From: malte_rennert at web.de (Malte Rennert) Date: Mon, 9 Feb 2004 13:59:54 +0100 Subject: [En-Nut-Discussion] Ethernut CF (WLAN) Interface In-Reply-To: References: Message-ID: <200402091359.54813.malte_rennert@web.de> Am Sonntag, 8. Februar 2004 11:17 schrieb Michael Fischer: > Who can help to design the CPLD? > It should be a Xilinx CPLD, because the software is free. > And I use here the Xilinx WebPack 6.1. Hello Michael, maybe I can help to design the CPLD. I have some experiences with Xilinx Webpack. I used the XC95.. CPLDs and the XC2S50 FPGA. But I don't have any experiences with Ethernut right now. Please contact me if you need my help. Best regards Malte From francois at asnone.com Mon Feb 9 16:54:42 2004 From: francois at asnone.com (Francois Rademeyer) Date: Mon, 9 Feb 2004 17:54:42 +0200 Subject: [En-Nut-Discussion] GPRS PAP problem Message-ID: <01c101c3ef25$0a7a6e10$1000a8c0@sonyfrademeyer> Hi all, Firstly there seems to be a bug in the latest "lcpout.c" file. The line : if ((nb = NutNetBufAlloc(0, NBAF_APPLICATION, rejected ? 6 : 12)) != 0) { should be: if ((nb = NutNetBufAlloc(0, NBAF_APPLICATION, rejected ? 12 : 6)) != 0) { My real problem is that PAP authentication messages seem to be ignored by my GPRS server. The server requires a blank username and password. I have tried blank. I have tried passwords. I have even tried rejecting the (AUTH=0xC023) request from the server. Still I'm being ignored (except for the latter where I get a TERMREQ when it is time for IPCP negotiation). Has anyone experienced this? Could it be that the server is speechless without PCOMP and ACOMP? Thanks in advance for any help. Cheers, Francois Rademeyer Here is a shortened version of my PPP debug output for a blank id/password: PPP < [LCP-1 CONFREQ (ACCM = 0x000A000)] PPP > [LCP-1 CONFREQ (MRU=1500)(ACCM = 0x0000000)(PCOMP)(ACOMP)(AUTH=0xC023)] PPP < [LCP-1 CONFREJ (PCOMP)(ACOMP)] PPP > [LCP-1 CONFACK (ACCM = 0x000A000)] PPP > [LCP-2 CONFREQ (MRU=1500)(ACCM = 0x0000000)(AUTH=0xC023)] PPP < [LCP-2 CONFACK (MRU=1500)(ACCM = 0x0000000)(AUTH=0xC023)] PPP < [PAP-3 AUTHREQ] ... 5 second delay PPP < [PAP-3 AUTHREQ] ... 5 second delay PPP < [PAP-3 AUTHREQ] ... 5 second delay PPP < [PAP-3 AUTHREQ] ... 5 second delay PPP < [PAP-3 AUTHREQ] ... 5 second delay PPP < [PAP-3 AUTHREQ] ... no auth reply received (timeout) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Oliver.Schulz at bong.de Mon Feb 9 16:56:46 2004 From: Oliver.Schulz at bong.de (Oliver Schulz) Date: Mon, 9 Feb 2004 16:56:46 +0100 Subject: AW: [En-Nut-Discussion] Missing lib directory in 3.4.1rc1 Message-ID: Hi Pavel and all, although the directories are definitely in CVS, they are obviously not checked out. If running an CVS update with '-d' option (create missing subdirs) after the checkout, the missing directories are finally created. Harald, perhaps it is a good idea to place some dummy files in the lib subdirs, to ensure that these dirs will be created on CVS checkout.. Cheers, Oliver. > -----Urspr?ngliche Nachricht----- > Von: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von > Pavel Celeda > Gesendet: Samstag, 7. Februar 2004 12:23 > An: Ethernut User Chat (English) > Betreff: [En-Nut-Discussion] Missing lib directory in 3.4.1rc1 > > > Hi, > > today I checked out Nut release candidate 3.4.1rc1 from CVS > > cvs -z3 > -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/ethernut co -r > nut-3_4-release nut > > and there is no lib/... directory available. > > with best regards > Pavel > > > > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From ethernut at objenv.com Sun Feb 8 01:42:38 2004 From: ethernut at objenv.com (Rich Wellner) Date: Sat, 07 Feb 2004 18:42:38 -0600 Subject: [En-Nut-Discussion] NutUdpSendTo problem In-Reply-To: <000001c3b9b3$cf7ce820$1601a8c0@p3> ("Lars Andersson"'s message of "Wed, 3 Dec 2003 16:40:41 +0100") References: <000001c3b9b3$cf7ce820$1601a8c0@p3> Message-ID: <87ptcq7669.fsf@objenv.com> I wonder if you guys can spot me doing something obviously wrong here. I call NutUdpSendTo and always get a -1 return. I see from the mail list archives that there was a buffer handling problem in NutUdpSendTo in the past, but I've checked my source and not only does this problem seem unrelated, but I have the patch for the buffer handling issue. If I change the dest ip to 207.252.251.233 and run ethereal on the dest node then I get 0 returns from NutUdpSendTo and the activity light on the ethernut lights up, but the packet is never seen at the destination. output: ip: 207.252.251.238 netmask: 255.255.255.248 gateway: 207.252.251.233 dest ip: 216.127.80.16 return: -1 return: -1 return: -1 Source: int main(void) { u_long baud = 115200; u_char i; u_long dest_addr; UDPSOCKET *udpsock; /* * Initialize the uart device. */ NutRegisterDevice(&devDebug0, 0, 0); freopen("uart0", "w", stdout); _ioctl(_fileno(stdout), UART_SETSPEED, &baud); NutSleep(200); printf("\n\nNut/OS %s HTTP Daemon...\n", NutVersionString()); #ifdef NUTDEBUG NutTraceTcp(stdout, 0); NutTraceOs(stdout, 0); NutTraceHeap(stdout, 0); NutTracePPP(stdout, 0); #endif /* * Register Ethernet controller. */ //if(NutRegisterDevice(&devSmsc111, 0, 0)) if (NutRegisterDevice(&devEth0, 0x8300, 5)) puts("Registering device failed"); /* * LAN configuration using EEPROM values or DHCP/ARP method. * If it fails, use fixed values. */ if (NutDhcpIfConfig("eth0", 0, 60000)) { u_char mac[] = { MYMAC }; u_long ip_addr = inet_addr(MYIP); u_long ip_mask = inet_addr(MYMASK); puts("EEPROM/DHCP/ARP config failed"); NutNetIfConfig("eth0", mac, ip_addr, ip_mask); } printf("ip: %s\n", inet_ntoa(confnet.cdn_ip_addr)); printf("netmask: %s\n", inet_ntoa(confnet.cdn_ip_mask)); printf("gateway: %s\n", inet_ntoa(confnet.cdn_gateway)); udpsock = NutUdpCreateSocket(0); dest_addr = inet_addr("216.127.80.16"); printf("dest ip: %s\n", inet_ntoa(dest_addr)); /* * We could do something useful here, like serving a watchdog. */ NutThreadSetPriority(254); for (;;) { printf("return: %d\n", NutUdpSendTo(udpsock, dest_addr, 2526, "test", 4)); NutSleep(1000); } } From g.kindel at stud.hs-wismar.de Mon Feb 9 10:48:09 2004 From: g.kindel at stud.hs-wismar.de (oggi) Date: Mon, 9 Feb 2004 10:48:09 +0100 Subject: [En-Nut-Discussion] Getting remote ip address Message-ID: Hello, I have a problem, with getting a ip address from an remote host, the ethernut is a server and waiting for a connection, when a computer connect i need his ip to send him data back, but i don't know where i can get his ip. thanks for helping, and sorry about my bad english georg kindel =================================================================== EASY and FREE access to your email anywhere: http://Mailreader.com/ =================================================================== From harald.kipp at egnite.de Mon Feb 9 19:15:57 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 09 Feb 2004 19:15:57 +0100 Subject: [En-Nut-Discussion] Getting remote ip address In-Reply-To: Message-ID: <5.1.1.6.0.20040209190704.0329bd08@egnite.de> Hi Georg, Sorry it took some time to pull your post from a large queue after the list server crash. If you subribe at http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion your posts will appear in the list without approval. Regarding your _real_ problem: With TCP, you don't worry about the remote IP. You simply send data back on the same socket (same connection). See the tcps sample. For UDP, you'll get the remote address (and port) from NutUdpReceiveFrom(). Here's a simple snippet to give you an idea: u_long raddr; <--- Remote's IP u_short rport; <--- Remote's port for (;;) { if ((got = NutUdpReceiveFrom(sock, &raddr, &rport, buff, sizeof(buff), 1000)) <= 0) { printf("Recv failed\n"); } else { //printf("R%d-%s:%u\n", got, inet_ntoa(raddr), rport); if (NutUdpSendTo(sock, raddr, LOCALPORT, buff, got)) { printf("Send failed\n"); } else { putchar('S'); } } } Harald From Baranov at intech21.com Mon Feb 9 19:45:05 2004 From: Baranov at intech21.com (Alexander Baranov) Date: Mon, 9 Feb 2004 13:45:05 -0500 Subject: [En-Nut-Discussion] One more reference to PCB design Message-ID: <001a01c3ef3c$d5da36f0$1101000a@Alex> http://www.ti.informatik.uni-bonn.de/Extern/documents/highspeedboarddesign.pdf Alexander Baranov From harald.kipp at egnite.de Mon Feb 9 20:04:10 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 09 Feb 2004 20:04:10 +0100 Subject: [En-Nut-Discussion] Ethernut 2 In-Reply-To: <20040208224141.493DC9E288@smtp-2.paradise.net.nz> Message-ID: <5.1.1.6.0.20040209191758.031d4640@egnite.de> Hi Douglas, >I am redesigning an EtherNut 1.3 daughter board (Quad UARTS, >RS485/232/IrDA/Flash RAM, RTC clock/calendar, etc etc) to work with the >newer EtherNut 2. I've done everything to make this as painless as possible. >As I am not sure my previous posting got through, I d like to summarise my >questions about the EtherNut 2: The mailing list was down. Took a few days (and hints from kind people) to detect this problem. >PE6 (INT6) is NOT used and can by used by my own design. PE6 is not used. In fact, Ethernut 2 may use more Port Bits than Ethernut 1, but this is all optional and jumper selectable. >Only RESET\ and not RESET goes to the expansion header (any plans to >change this???) No, there are no plans to further change the Ethernut Expansion Connector. Take Ethernut 2 as final... OK, if we change this, there will be jumper. :-) >I can use 0xFE00 0xFEFF to memory map my own design (if not, what ranges >are available?). 0xFFXX is the bank select register. However, this is decoded in the CPLD and can be changed. I'll publish an Ethernut application to reprogram the CPLD soon. No need for a Xilinx JTAG adapter. Also the LAN91C111 address is decoded in the CPLD and thus changable. It currently located at 0xC000. We intentionally put the SMSC Controller at the beginning, so the upper regions are kept available for slower hardware. Remember, that the ATmega can specifically add memory cycles on upper regions. I'd suggest to use 0xDXXX for extension without waits and 0xEXXX for slow hardware. >And lastly, the daughter board can draw at a peak, 5v up to 1.7 amps. That's a lot. >In the past, the daughter board has a 5v 3A power supply that supplies the >5v to the EtherNut 1.3 via the expansion header (we remove the 5v >regulator from the EtherNut). Yes, the Ethernut 2 isn't still perfect. An additional diode bridging the 5V regulator would avoid to have it removed...sigh. But why not supply the DC pin with unregulated power (Expansion pin 10)? >Is it possible to upgrade the LM1086(1.5A) to a LM1085 (3A) or a LM1084(5A)? Sure, that was one reason why I chose this somewhat exotic regulator. However, your input voltage should be as low as possible, luckily LM108x are LDOs. 6.5V may already work, 7V is stable and fine. Using higher input voltages will produce a lot of heat with 1.7 Amps. And Ethernut 2 already becomes quite warm because of the 100 MBit controller. But the major problem are the traces and the rectifier bridge. Theoretically the unregulated DC trace width is sufficient for 1.85 Amps only, but they may already warm up. Worse, the rectifier takes 800 mA max. They are available for 1 Amp, but I do not know about any higher current. The 5V traces are no problem because Ethernut is a four layer board and has it's own supply layer, directly connected to the expansion port. >What else would need to change (F1 to 3A or 5A)? Right, the fuse needs to be changed. >Would this work with the current board design (track width, vias etc)? If there are just _peaks_ of 1.7 Amps, changing the regulator, replacing the fuse and shorterning the rectifier should work. But it depends on what you name peaks and how often they may occur or what's the average current. It's mainly a heat problem and thus depends on the environment. >I guess this will become more of an issue as more and more daughter / >expansion boards are developed! The few power hungry boards we designed got their own regulators and used the DC pin to supply Ethernut. This design has a better heat distribution. >The other alternative is to put a LM1084 on the daughter board, and >removing the LM1086 from the EtherNut, which would not be my preference. See above. Harald From harald.kipp at egnite.de Mon Feb 9 20:40:20 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 09 Feb 2004 20:40:20 +0100 Subject: [En-Nut-Discussion] NutUdpSendTo problem In-Reply-To: <87ptcq7669.fsf@objenv.com> References: <000001c3b9b3$cf7ce820$1601a8c0@p3> <000001c3b9b3$cf7ce820$1601a8c0@p3> Message-ID: <5.1.1.6.0.20040209201809.03238ae8@egnite.de> Hi Francois, At 18:42 07.02.2004 -0600, you wrote: >I wonder if you guys can spot me doing something obviously wrong here. I call >NutUdpSendTo and always get a -1 return. I see from the mail list archives >that there was a buffer handling problem in NutUdpSendTo in the past, but I've >checked my source and not only does this problem seem unrelated, but I have >the patch for the buffer handling issue. If I change the dest ip to >207.252.251.233 and run ethereal on the dest node then I get 0 returns from >NutUdpSendTo and the activity light on the ethernut lights up, but the packet >is never seen at the destination. Indeed. If 216.127.80.16 produces errors and 207.252.251.233 doesn't, then this is obviously no buffer problem. Frankly, I do not have the slightest idea, why Ethereal doesn't show the UDP packet on 207.252.251.233 after you set the destination to this IP. I have to admit too, that I never tried routing with with Ethernut's UDP, but, as routing is implemented in the IP layer and used by TCP too, I'm quite sure that this should work. I checked your network/netmask setup twice, but it looks OK to me. In your output EEPROM/DHCP/ARP config failed never appears, so you are using DHCP. May be there's the problem. Can you please try to use NutNetIfConfig("eth0", mac, ip_addr, ip_mask); NutIpRouteAdd(0, 0, inet_addr("207.252.251.233"), &devEth0); instead of NutDhcpIfConfig()? Still, Ethereal _must_ show something...at least the ARP request from Ethernut. Harald From harald.kipp at egnite.de Mon Feb 9 20:42:20 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 09 Feb 2004 20:42:20 +0100 Subject: [En-Nut-Discussion] NutUdpSendTo problem Message-ID: <5.1.1.6.0.20040209204134.031ff668@egnite.de> Oops, pardon me. Should have been Hi Rich, not Hi Francois, From harald.kipp at egnite.de Mon Feb 9 20:58:00 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 09 Feb 2004 20:58:00 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <20040205114446.54C43400917@mwinf0301.wanadoo.fr> References: <5.1.1.6.0.20040205105833.031cf3e0@egnite.de> Message-ID: <5.1.1.6.0.20040209204553.03227d50@egnite.de> Hi Jean Pierre, At 12:42 05.02.2004 +0100, you wrote: >I am not sure that Nut/OS needs a great "CPU upsizing" today but it needs to >become first more reliable before migrate! Do I detect hidden critics here? :-) Nut/OS will never be as reliable as larger systems, which offer MMU and protected memory regions. The cooperative threading adds additional traps. That's why it's more difficult to write reliable applications for Nut/OS compared to Linux. >Other bigger OS are in place and could be a better choice for bigger CPUs to >fill quickly 512K of Flash ;-). > For example, if you want to create an MP3 Ethernet player, you can use hardware. If you want to add Ogg Vorbis, you are lost (no idea, wether there are any hardware de/encoders available in the meantime, just to give an example). So you need raw power, but no eCos, Linux or whatever. Just something simple with a little bit TCP would do. That's at least my motivation. I'd like to see my GameBoy playing MPEG movies, which I transfered on it's CompactFlash card via FTP. Harald From Douglas.Pearless at pearless.co.nz Mon Feb 9 21:07:14 2004 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Tue, 10 Feb 2004 09:07:14 +1300 Subject: [En-Nut-Discussion] Ethernut 2 In-Reply-To: <5.1.1.6.0.20040209191758.031d4640@egnite.de> Message-ID: <20040209200124.6A66BADF66@smtp-3.paradise.net.nz> Hi Harald, Thanks for the input. In Summary: We will use: INT6 (PE6), 0xDXXX, power the EtherNut 2 from my daughter board (5v switch mode power supply to keep it cool). Note the 1.7A is for a specialised customer board (grand daughter board ;-) )that plugs into my daughter board as the daughter board itself on draws a few hundred mA. And lastly, we are looking to GPL the design, minus our customers commercially sensitive bit, I assume people would like a board that has these extra features? (we used the Oxford ox16c954, check out http://www.oxsemi.co.uk/download/standard/dsheets/ox16c954ds.pdf for more details on the chip itself) I notice that the template expansion board for the EtherNut 2 requires me to upgrade to Eagle v4.11, and changes of a version that I can open via Eagle 4.09? Cheer Douglas -----Original Message----- From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Harald Kipp Sent: Tuesday, 10 February 2004 8:04 a.m. To: Ethernut User Chat (English) Subject: Re: [En-Nut-Discussion] Ethernut 2 Hi Douglas, >I am redesigning an EtherNut 1.3 daughter board (Quad UARTS, >RS485/232/IrDA/Flash RAM, RTC clock/calendar, etc etc) to work with the >newer EtherNut 2. I've done everything to make this as painless as possible. >As I am not sure my previous posting got through, I d like to summarise my >questions about the EtherNut 2: The mailing list was down. Took a few days (and hints from kind people) to detect this problem. >PE6 (INT6) is NOT used and can by used by my own design. PE6 is not used. In fact, Ethernut 2 may use more Port Bits than Ethernut 1, but this is all optional and jumper selectable. >Only RESET\ and not RESET goes to the expansion header (any plans to >change this???) No, there are no plans to further change the Ethernut Expansion Connector. Take Ethernut 2 as final... OK, if we change this, there will be jumper. :-) >I can use 0xFE00 0xFEFF to memory map my own design (if not, what ranges >are available?). 0xFFXX is the bank select register. However, this is decoded in the CPLD and can be changed. I'll publish an Ethernut application to reprogram the CPLD soon. No need for a Xilinx JTAG adapter. Also the LAN91C111 address is decoded in the CPLD and thus changable. It currently located at 0xC000. We intentionally put the SMSC Controller at the beginning, so the upper regions are kept available for slower hardware. Remember, that the ATmega can specifically add memory cycles on upper regions. I'd suggest to use 0xDXXX for extension without waits and 0xEXXX for slow hardware. >And lastly, the daughter board can draw at a peak, 5v up to 1.7 amps. That's a lot. >In the past, the daughter board has a 5v 3A power supply that supplies the >5v to the EtherNut 1.3 via the expansion header (we remove the 5v >regulator from the EtherNut). Yes, the Ethernut 2 isn't still perfect. An additional diode bridging the 5V regulator would avoid to have it removed...sigh. But why not supply the DC pin with unregulated power (Expansion pin 10)? >Is it possible to upgrade the LM1086(1.5A) to a LM1085 (3A) or a LM1084(5A)? Sure, that was one reason why I chose this somewhat exotic regulator. However, your input voltage should be as low as possible, luckily LM108x are LDOs. 6.5V may already work, 7V is stable and fine. Using higher input voltages will produce a lot of heat with 1.7 Amps. And Ethernut 2 already becomes quite warm because of the 100 MBit controller. But the major problem are the traces and the rectifier bridge. Theoretically the unregulated DC trace width is sufficient for 1.85 Amps only, but they may already warm up. Worse, the rectifier takes 800 mA max. They are available for 1 Amp, but I do not know about any higher current. The 5V traces are no problem because Ethernut is a four layer board and has it's own supply layer, directly connected to the expansion port. >What else would need to change (F1 to 3A or 5A)? Right, the fuse needs to be changed. >Would this work with the current board design (track width, vias etc)? If there are just _peaks_ of 1.7 Amps, changing the regulator, replacing the fuse and shorterning the rectifier should work. But it depends on what you name peaks and how often they may occur or what's the average current. It's mainly a heat problem and thus depends on the environment. >I guess this will become more of an issue as more and more daughter / >expansion boards are developed! The few power hungry boards we designed got their own regulators and used the DC pin to supply Ethernut. This design has a better heat distribution. >The other alternative is to put a LM1084 on the daughter board, and >removing the LM1086 from the EtherNut, which would not be my preference. See above. Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.580 / Virus Database: 367 - Release Date: 6/02/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.580 / Virus Database: 367 - Release Date: 6/02/2004 From olischulz at web.de Mon Feb 9 21:31:59 2004 From: olischulz at web.de (Oliver Schulz) Date: Mon, 9 Feb 2004 21:31:59 +0100 Subject: AW: [En-Nut-Discussion] NutUdpSendTo problem In-Reply-To: <5.1.1.6.0.20040209201809.03238ae8@egnite.de> Message-ID: <000e01c3ef4b$c50cc540$5b42a8c0@ose.de> Hi Rich & Harald, some additional annotations to Haralds posting: > I have to admit too, that I never tried routing with > with Ethernut's UDP, but, as routing is implemented > in the IP layer and used by TCP too, I'm quite sure > that this should work. While testing the sntp stuff, I extensively used routing for UDP packets and it worked fine. I always took directly ntp1.ptb.de as time server. > > In your output > EEPROM/DHCP/ARP config failed > never appears, so you are using DHCP. May be there's the > problem. Can you please try to use Well, but DHCP is even *not* used if in confnet struct a valid ip address and subnet mask is stored. NutDhcpIfConfig only starts the dhcp thread if no ip address (0.0.0.0) is stored in EEPROM. Otherwise the EEPROM configuration is used to configure the interface (which is not bad at all), but the stored gateway ip address is unfortunately ignored and then no default route is available. I already commited a bugfix to nut-3_4-release, which was initially intended to be applied in HEAD branch only. ...Uuhhh merging from HEAD branch, hope Harald will not kill me for this... Regards, Oliver. From ethernut at objenv.com Mon Feb 9 21:39:02 2004 From: ethernut at objenv.com (Rich Wellner) Date: Mon, 09 Feb 2004 14:39:02 -0600 Subject: [En-Nut-Discussion] NutUdpSendTo problem In-Reply-To: <5.1.1.6.0.20040209201809.03238ae8@egnite.de> (Harald Kipp's message of "Mon, 09 Feb 2004 20:40:20 +0100") References: <000001c3b9b3$cf7ce820$1601a8c0@p3> <000001c3b9b3$cf7ce820$1601a8c0@p3> <5.1.1.6.0.20040209201809.03238ae8@egnite.de> Message-ID: <87vfmg56op.fsf@objenv.com> Harald Kipp writes: > In your output > EEPROM/DHCP/ARP config failed > never appears, so you are using DHCP. May be there's the > problem. Can you please try to use > > NutNetIfConfig("eth0", mac, ip_addr, ip_mask); > NutIpRouteAdd(0, 0, inet_addr("207.252.251.233"), &devEth0); > > instead of NutDhcpIfConfig()? Well, this is something to try anyway. And I confess I hadn't noticed that the "config failed" line wasn't in the output. *I* know that there is no DHCP server so somehow developed a blind spot for this. I'll try the above and see what happens. If nothing else perhaps poking it with a different stick will produce a different error. Thanks for having a look and making a suggestion. rw2 From harald.kipp at egnite.de Mon Feb 9 21:34:16 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 09 Feb 2004 21:34:16 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <402381BE.4070605@telogis.com> References: <5.1.1.6.0.20040205105833.031cf3e0@egnite.de> <5.1.1.6.0.20040205105833.031cf3e0@egnite.de> Message-ID: <5.1.1.6.0.20040209210115.032d1f68@egnite.de> Hi Ralph, At 00:59 07.02.2004 +1300, you wrote: >Harald Kipp wrote >> >>I'm afraid, that it's not that simple. As far as I >>understood, the low cost thumbs are running with >>32 bit access in internal memory only. Having Nut/OS >>and the application in on-chip RAM is an advantage. > >But running thumb from 16 bit memory is optimal. It's all a question of >what the goal is. To me it's more performance ( to allow simpler >programing) with no more cost. But isn't 32 bit access twice as fast as 16 bit? The AT91R40008 comes with sufficient internal RAM. >>On the other hand, external flash gives more flexibility. >>It may contain the image _plus_ a file system. > >Nand flash is always cheaper for a file system (and I have a nut >compatible nand flash file system almost ready to release!) I do not know much about differences in flash memory techniques...but nand types seems to be hot. A flash file system is indeed something I'm missing. Using Michael's FAT is OK for reading, but would soon wear out the FAT table area on excessive writing. I guess, wear out is still a problem with nand flash, isn't it? >I guess at the end of the day, what is NutOS trying to be? Is it a new >ecos in the making? Does it (Do we?) support process loading? What about >AVR's - does it get so heavy as to leave them behind? Process loading is a big word...but how about a tiny little shared lib. :-) You may know that my company created Coconut, a multiport RS232, using ATmega128 as double UARTs. They are running Nut/OS (internal RAM only, of course, no TCP), which made the task of creating "intelligent" UARTs very simple. I'd also like to see Nut/OS running in an ISP dongle, LCD interface etc. >Interesting article in Linux world this month - about open source trying >to compete with itself (http://www.linuxworld.com/magazine/?issueid=352&de=1) Somehow, Open Source implicitely includes competion. If you are unsatisfied with a software project, take the source, rename it (keeping copyrights, of course) and create a new project. It's that easy. I do not follow the author's view in some points. Like he critizised "Quiet, the boss is speaking". Everybody is free to take Nut/OS, call it NewYork/OS and make it look completely different. As long as it is called Nut/OS and as long as I'm interested in it, I reserve the right to accept or deny modifications. But I try to be as tolerant as possible, but also as conservative as possible to protect our and other's investments. And it's by far not like "you're either with us or against us". My Ethernuts are happily running Contiki from time to time and the only reason for not seeing AvrX is the lack of time. Ignorance is not a fixed part of Open Source. It an adjective of some people, who cry loudest in newsgroups and mailing lists. The silent majority is very tolerant. But to get to the point, IMHO Nut/OS should keep it's kernel as simple as possible. Applications may use goodies like file systems or message queues. My view of the system is like the C programming language: Very simple, very near to the underlying hardware, but still very portable. Equipped with a powerful runtime library. Harald From ethernut at objenv.com Mon Feb 9 21:43:35 2004 From: ethernut at objenv.com (Rich Wellner) Date: Mon, 09 Feb 2004 14:43:35 -0600 Subject: AW: [En-Nut-Discussion] NutUdpSendTo problem In-Reply-To: <000e01c3ef4b$c50cc540$5b42a8c0@ose.de> ("Oliver Schulz"'s message of "Mon, 9 Feb 2004 21:31:59 +0100") References: <000e01c3ef4b$c50cc540$5b42a8c0@ose.de> Message-ID: <87r7x456h4.fsf@objenv.com> "Oliver Schulz" writes: > Hi Rich & Harald, > > some additional annotations to Haralds posting: > >> I have to admit too, that I never tried routing with with Ethernut's UDP, >> but, as routing is implemented in the IP layer and used by TCP too, I'm >> quite sure that this should work. > While testing the sntp stuff, I extensively used routing for UDP packets and > it worked fine. I always took directly ntp1.ptb.de as time server. Is this code available in any form? I'd be happy at this point to have *any* code working and then work my way back up from there. >> In your output EEPROM/DHCP/ARP config failed never appears, so you are >> using DHCP. May be there's the problem. Can you please try to use > Well, but DHCP is even *not* used if in confnet struct a valid ip address > and subnet mask is stored. NutDhcpIfConfig only starts the dhcp thread if no > ip address (0.0.0.0) is stored in EEPROM. Otherwise the EEPROM > configuration is used to configure the interface (which is not bad at all), > but the stored gateway ip address is unfortunately ignored and then no > default route is available. Ah. Yes, this makes sense. But perhaps Harald's test does me no good then. Well, I'll try it anyway. Again, poke with a different stick, who knows. I'm also going to try converting this to a TCP stack and see what happens. I suppose there is a remote possibility that I have a physical layer problem. rw2 From olischulz at web.de Mon Feb 9 22:12:46 2004 From: olischulz at web.de (Oliver Schulz) Date: Mon, 9 Feb 2004 22:12:46 +0100 Subject: AW: AW: [En-Nut-Discussion] NutUdpSendTo problem In-Reply-To: <87r7x456h4.fsf@objenv.com> Message-ID: <000f01c3ef51$77a88c70$5b42a8c0@ose.de> Hi Rich, > > While testing the sntp stuff, I extensively used routing > for UDP packets and > > it worked fine. I always took directly ntp1.ptb.de as time server. > > Is this code available in any form? I'd be happy at this > point to have *any* > code working and then work my way back up from there. Of couse. The sntp protocol is already included in Nut/OS. Look in pro/sntp.c and include/pro/sntp.h for some details. Unfortunately I missed to write some dox about sntp jet (sorry). In http://www.ethernut.de/arc/ostime-104.zip you'll find a readme file with some explanations. So long, Oliver. From zodianet at wanadoo.fr Mon Feb 9 22:32:15 2004 From: zodianet at wanadoo.fr (Zodianet) Date: Mon, 9 Feb 2004 22:32:15 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms (Porsche 911 is better than a Golf but sorry , I need a small car) In-Reply-To: <5.1.1.6.0.20040209204553.03227d50@egnite.de> Message-ID: <20040209213418.5988A1BFD3E8@mwinf0102.wanadoo.fr> Harald, I have just no time to debug Nut/OS and even if it is small, it's complex. It's very easy to spend a lot of time for this task. I need a reliable OS like other users I think. For my job, I worked on a BSD stack adaptation because the native stack of a well-known real-time OS was bugged(... and very expensive). Big CPU, memories, big problems ... But for my friends, small != TCP/IP. Definitively. Instead BSD & Linux, nothing.... Of course, a Porsche 911 is better than a Golf but I need a small car. Smallest as possible. With Nut/OS, I do the same things with I=100mA and 32K of RAM with a near cold board. I am nicely surprised. So small! Perfect for my needs. And it works.(the last TCP updates are very good). Really, no hidden critics :-) But reliability very is important ;-) Nut/OS has no MMU. Yes, but MMU is only useful when tasks are bugged. Waste a little time to create an abstraction layer and then develop , test, debug your high layer applications on confortable environment e.g. PC, linux, Windows (equiped with MMU) and without real-time constraints (very important). Create I/O simulators if needed. And when all is OK,compile and test your software on the target. (in fact, the both compilers windows are always open here and point to the same sources) And... maintain dual environment for portability and bug tracking. In fact, you will save a lot of time. No MMU is no problem. Except for 10 exp(6) lines of code, system, low layers or I/O oriented applications. Jean Pierre -----Message d'origine----- De : en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de] De la part de Harald Kipp Envoy? : lundi 9 f?vrier 2004 20:58 ? : Ethernut User Chat (English) Objet : RE: [En-Nut-Discussion] Supporting Other Target Platforms Hi Jean Pierre, At 12:42 05.02.2004 +0100, you wrote: >I am not sure that Nut/OS needs a great "CPU upsizing" today but it >needs to become first more reliable before migrate! Do I detect hidden critics here? :-) Nut/OS will never be as reliable as larger systems, which offer MMU and protected memory regions. The cooperative threading adds additional traps. That's why it's more difficult to write reliable applications for Nut/OS compared to Linux. >Other bigger OS are in place and could be a better choice for bigger >CPUs to fill quickly 512K of Flash ;-). > For example, if you want to create an MP3 Ethernet player, you can use hardware. If you want to add Ogg Vorbis, you are lost (no idea, wether there are any hardware de/encoders available in the meantime, just to give an example). So you need raw power, but no eCos, Linux or whatever. Just something simple with a little bit TCP would do. That's at least my motivation. I'd like to see my GameBoy playing MPEG movies, which I transfered on it's CompactFlash card via FTP. Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From thomas at juletraesfoden.dk Mon Feb 9 22:36:36 2004 From: thomas at juletraesfoden.dk (=?iso-8859-1?Q?Thomas_M=F8rch?=) Date: Mon, 9 Feb 2004 22:36:36 +0100 Subject: [En-Nut-Discussion] eaglecad template Message-ID: <001801c3ef54$cbabef80$6402a8c0@laptop> Hey, why didn't I see that there finaly was a template for expansion boards.. Thanks Harald... Now I can concentrate on making my LCD interface, and make a driver for it.. (Unless someone already has made a driver for the SED1335 LCD controler?) Regards Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethernut at objenv.com Mon Feb 9 22:52:30 2004 From: ethernut at objenv.com (Rich Wellner) Date: Mon, 09 Feb 2004 15:52:30 -0600 Subject: AW: AW: [En-Nut-Discussion] NutUdpSendTo problem In-Reply-To: <000f01c3ef51$77a88c70$5b42a8c0@ose.de> ("Oliver Schulz"'s message of "Mon, 9 Feb 2004 22:12:46 +0100") References: <000f01c3ef51$77a88c70$5b42a8c0@ose.de> Message-ID: <87n07r6hup.fsf@objenv.com> "Oliver Schulz" writes: >> Is this code available in any form? I'd be happy at this point to have >> *any* code working and then work my way back up from there. > Of couse. The sntp protocol is already included in Nut/OS. Look in > pro/sntp.c and include/pro/sntp.h for some details. I just downloaded 3.3.2 and don't see it... > Unfortunately I missed to write some dox about sntp jet (sorry). In > http://www.ethernut.de/arc/ostime-104.zip you'll find a readme file with > some explanations. I see the files are in this zip, did you mean for me to unpack this into an existing tree? rw2 From zodianet at wanadoo.fr Mon Feb 9 22:56:55 2004 From: zodianet at wanadoo.fr (Zodianet) Date: Mon, 9 Feb 2004 22:56:55 +0100 Subject: [En-Nut-Discussion] eaglecad template In-Reply-To: <001801c3ef54$cbabef80$6402a8c0@laptop> Message-ID: <20040209215858.00A571BFFFBA@mwinf0102.wanadoo.fr> Do you know that? http://www.ramtex.dk/products/lcdd1335.htm _____ De : en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de] De la part de Thomas M?rch Envoy? : lundi 9 f?vrier 2004 22:37 ? : Ethernut User Chat (English) Objet : [En-Nut-Discussion] eaglecad template Hey, why didn't I see that there finaly was a template for expansion boards.. Thanks Harald... Now I can concentrate on making my LCD interface, and make a driver for it.. (Unless someone already has made a driver for the SED1335 LCD controler?) Regards Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at juletraesfoden.dk Mon Feb 9 23:02:35 2004 From: thomas at juletraesfoden.dk (=?iso-8859-1?Q?Thomas_M=F8rch?=) Date: Mon, 9 Feb 2004 23:02:35 +0100 Subject: [En-Nut-Discussion] eaglecad template References: <20040209215858.00A571BFFFBA@mwinf0102.wanadoo.fr> Message-ID: <004301c3ef58$6d076eb0$6402a8c0@laptop> No, haven't seen that before, but anyway it's not GPL'ed code.. so won't do! Would like to contribute something to the ethernut public ;) Regards Thomas ----- Original Message ----- From: Zodianet To: 'Ethernut User Chat (English)' Sent: Monday, February 09, 2004 10:56 PM Subject: RE: [En-Nut-Discussion] eaglecad template Do you know that? http://www.ramtex.dk/products/lcdd1335.htm ------------------------------------------------------------------------------ De : en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de] De la part de Thomas M?rch Envoy? : lundi 9 f?vrier 2004 22:37 ? : Ethernut User Chat (English) Objet : [En-Nut-Discussion] eaglecad template Hey, why didn't I see that there finaly was a template for expansion boards.. Thanks Harald... Now I can concentrate on making my LCD interface, and make a driver for it.. (Unless someone already has made a driver for the SED1335 LCD controler?) Regards Thomas ------------------------------------------------------------------------------ _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion -------------- next part -------------- An HTML attachment was scrubbed... URL: From olischulz at web.de Mon Feb 9 23:11:07 2004 From: olischulz at web.de (Oliver Schulz) Date: Mon, 9 Feb 2004 23:11:07 +0100 Subject: AW: AW: AW: [En-Nut-Discussion] NutUdpSendTo problem In-Reply-To: <87n07r6hup.fsf@objenv.com> Message-ID: <001f01c3ef59$9e9d69b0$5b42a8c0@ose.de> Hi Rich, sorry, it's a bit late for me and it seems, that I'm already sleeping.. :-) > I just downloaded 3.3.2 and don't see it... I forgot to say, that this sntp stuff is in CVS only, and not yet in the last official release of Nut/OS. Please use cvs to obtain the branch 'nut-3_4-release'. If your are new to cvs, I can explain the useage, but not in this mailing list. We should use then private email (mailto:olischulz at web.de). Another possibility is to use a cvs snapshot of the 3.4 release branch. You can find the latest at http://www.ethernut.de/arc/ethernut-3.4.1-rc1.tar.bz2 or look at http://www.ethernut.de/en/download.html for further infomation. But please note, that the latest bugfixes are not in the archive file, so I would prefer the cvs method. > > I see the files are in this zip, did you mean for me to > unpack this into an > existing tree? Well, I hope this is still possible. Before the stuff were added to the cvs, this zip file was intended to merge the sntp and time functions into an existing tree. But since end of november 2003, I didn't test it any longer. If you use cvs, you won't have any problems... (hopyfully :-) Cheers, Oliver. From ralph.mason at telogis.com Tue Feb 10 05:17:58 2004 From: ralph.mason at telogis.com (Ralph Mason) Date: Tue, 10 Feb 2004 17:17:58 +1300 Subject: [En-Nut-Discussion] Supporting Other Target Platforms (Porsche 911 is better than a Golf but sorry , I need a small car) In-Reply-To: <20040209213418.5988A1BFD3E8@mwinf0102.wanadoo.fr> References: <20040209213418.5988A1BFD3E8@mwinf0102.wanadoo.fr> Message-ID: <40285B76.5010802@telogis.com> Zodianet wrote: >Waste a little time to create an abstraction layer and then develop , test, >debug your high layer applications on confortable environment e.g. PC, >linux, Windows (equiped with MMU) and without real-time constraints (very >important). Create I/O simulators if needed. >And when all is OK,compile and test your software on the target. >(in fact, the both compilers windows are always open here and point to the >same sources) >And... maintain dual environment for portability and bug tracking. >In fact, you will save a lot of time. No MMU is no problem. >Except for 10 exp(6) lines of code, system, low layers or I/O oriented >applications. > > I have already done this for windows, and can run and debug the complete NutOS (except Ethernet drivers) using visual stido. Ralph From tyou at i-da.co.jp Tue Feb 10 06:10:03 2004 From: tyou at i-da.co.jp (TYOU) Date: Tue, 10 Feb 2004 14:10:03 +0900 Subject: [En-Nut-Discussion] Supporting Other Target Platforms In-Reply-To: <5.1.1.6.0.20040209210115.032d1f68@egnite.de> References: <5.1.1.6.0.20040205105833.031cf3e0@egnite.de> <5.1.1.6.0.20040205105833.031cf3e0@egnite.de> <5.1.1.6.0.20040209210115.032d1f68@egnite.de> Message-ID: <402867AB.1010505@i-da.co.jp> hi , Guys I think RISC186 series MCU from www.rdc.com.tw is a choice for Nut/OS. Low cost, high performance, easy available C compilier (BC), and even with 2 10/100M MAC controllers on chip(*R2020C *); SDRAM controller and UART with FIFO. http://www.rdc.com.tw/ProductInfo.asp As for NAND FLASH, it is more appropriate for file system because it has smaller sector size than NOR type FLASH. Coming with ATMEL ethernet develop kit, there is a simple linear flash file system, but it has not been opimized for writing. YAFFS is a portable ffs with embedded support, but it has strict license. Ralph! Waiting for your release! :-) Tyou From zodianet at wanadoo.fr Tue Feb 10 08:28:34 2004 From: zodianet at wanadoo.fr (Zodianet) Date: Tue, 10 Feb 2004 08:28:34 +0100 Subject: [En-Nut-Discussion] Supporting Other Target Platforms (Porsche911 is better than a Golf but sorry , I need a small car) In-Reply-To: <40285B76.5010802@telogis.com> Message-ID: <20040210073037.6422D18000FE@mwinf0903.wanadoo.fr> Lucky boy! fdopen doesn't work here with winsock, is this problem resolved for you ? So, I/O streams are emulated by not very attractive send/recv (a packet of fputc() may crash XP). JP >Waste a little time to create an abstraction layer and then develop , >test, debug your high layer applications on confortable environment >e.g. PC, linux, Windows (equiped with MMU) and without real-time >constraints (very important). Create I/O simulators if needed. >And when all is OK,compile and test your software on the target. >(in fact, the both compilers windows are always open here and point to >the same sources) And... maintain dual environment for portability and >bug tracking. >In fact, you will save a lot of time. No MMU is no problem. >Except for 10 exp(6) lines of code, system, low layers or I/O oriented >applications. > > I have already done this for windows, and can run and debug the complete NutOS (except Ethernet drivers) using visual stido. Ralph _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From ralph.mason at telogis.com Tue Feb 10 08:35:39 2004 From: ralph.mason at telogis.com (Ralph Mason) Date: Tue, 10 Feb 2004 20:35:39 +1300 Subject: [En-Nut-Discussion] Supporting Other Target Platforms (Porsche911 is better than a Golf but sorry , I need a small car) In-Reply-To: <20040210073037.6422D18000FE@mwinf0903.wanadoo.fr> References: <20040210073037.6422D18000FE@mwinf0903.wanadoo.fr> Message-ID: <402889CB.7050009@telogis.com> I have written windows comport drivers for windows. Then use an external modem, with ppp. Ralph > >Lucky boy! >fdopen doesn't work here with winsock, is this problem resolved for you ? >So, I/O streams are emulated by not very attractive send/recv (a packet of >fputc() may crash XP). >JP > > > > >>Waste a little time to create an abstraction layer and then develop , >>test, debug your high layer applications on confortable environment >>e.g. PC, linux, Windows (equiped with MMU) and without real-time >>constraints (very important). Create I/O simulators if needed. >>And when all is OK,compile and test your software on the target. >>(in fact, the both compilers windows are always open here and point to >>the same sources) And... maintain dual environment for portability and >>bug tracking. >>In fact, you will save a lot of time. No MMU is no problem. >>Except for 10 exp(6) lines of code, system, low layers or I/O oriented >>applications. >> >> >> >> > >I have already done this for windows, and can run and debug the complete >NutOS (except Ethernet drivers) using visual stido. > >Ralph > >_______________________________________________ >En-Nut-Discussion mailing list >En-Nut-Discussion at egnite.de >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > >_______________________________________________ >En-Nut-Discussion mailing list >En-Nut-Discussion at egnite.de >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > From zodianet at wanadoo.fr Tue Feb 10 08:44:49 2004 From: zodianet at wanadoo.fr (Zodianet) Date: Tue, 10 Feb 2004 08:44:49 +0100 Subject: [En-Nut-Discussion] Realtek 8019AS second sourced? In-Reply-To: <20040210073037.6422D18000FE@mwinf0903.wanadoo.fr> Message-ID: <20040210074651.ED23B1800144@mwinf0904.wanadoo.fr> The Eth chip of my Ethernut 1.3 is a RMC RTL8019AS. It's a Realtek compatible? or Realtek chip? Is 8019AS second sourced? Jean Pierre From togrady at comtech.uk.com Tue Feb 10 10:24:58 2004 From: togrady at comtech.uk.com (Trevor O'Grady) Date: Tue, 10 Feb 2004 09:24:58 -0000 Subject: [En-Nut-Discussion] Supporting Other Target Platforms (Porsche911 is better than a Golf but sorry , I need a small car) In-Reply-To: <40285B76.5010802@telogis.com> Message-ID: Ralph, This is very interesting. I was considering doing something like this. I have done this several times in the past for other systems and it is well worth the effort. You find bugs that otherwise would not be found in normal testing on the hardware. You can usually write 90% of your application in this nice environment. Is this something you would be willing to share ? Regards Trevor -----Original Message----- From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de]On Behalf Of Ralph Mason Sent: 10 February 2004 04:18 To: Ethernut User Chat (English) Subject: Re: [En-Nut-Discussion] Supporting Other Target Platforms (Porsche911 is better than a Golf but sorry , I need a small car) Zodianet wrote: >Waste a little time to create an abstraction layer and then develop , test, >debug your high layer applications on confortable environment e.g. PC, >linux, Windows (equiped with MMU) and without real-time constraints (very >important). Create I/O simulators if needed. >And when all is OK,compile and test your software on the target. >(in fact, the both compilers windows are always open here and point to the >same sources) >And... maintain dual environment for portability and bug tracking. >In fact, you will save a lot of time. No MMU is no problem. >Except for 10 exp(6) lines of code, system, low layers or I/O oriented >applications. > > I have already done this for windows, and can run and debug the complete NutOS (except Ethernet drivers) using visual stido. Ralph _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From harald.kipp at egnite.de Tue Feb 10 10:36:47 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 10 Feb 2004 10:36:47 +0100 Subject: [En-Nut-Discussion] Realtek 8019AS second sourced? In-Reply-To: <20040210074651.ED23B1800144@mwinf0904.wanadoo.fr> References: <20040210073037.6422D18000FE@mwinf0903.wanadoo.fr> Message-ID: <5.1.1.6.0.20040210103444.01bbb200@egnite.de> I found a few links on Google only, no real info. Mh...quite interesting. Does anybody know more about this? Harald At 08:44 10.02.2004 +0100, you wrote: > >The Eth chip of my Ethernut 1.3 is a RMC RTL8019AS. >It's a Realtek compatible? or Realtek chip? >Is 8019AS second sourced? >Jean Pierre From j.v.d.stoel at stream-it.nl Tue Feb 10 12:08:19 2004 From: j.v.d.stoel at stream-it.nl (Johan van der Stoel (Streamit)) Date: Tue, 10 Feb 2004 12:08:19 +0100 Subject: [En-Nut-Discussion] RE: RMC RTL8019AS In-Reply-To: <20040210110004.1C7412F42A1@p15095813.pureserver.info> Message-ID: <001301c3efc6$30fa50e0$2802a8c0@p42400> Dear Jean Pierre, This is just the Realtek chip. Just have a look at the datasheet and you will see the same logo. Johan Date: Tue, 10 Feb 2004 08:44:49 +0100 From: "Zodianet" Subject: RE: [En-Nut-Discussion] Realtek 8019AS second sourced? To: "'Ethernut User Chat (English)'" Message-ID: <20040210074651.ED23B1800144 at mwinf0904.wanadoo.fr> Content-Type: text/plain; charset="us-ascii" The Eth chip of my Ethernut 1.3 is a RMC RTL8019AS. It's a Realtek compatible? or Realtek chip? Is 8019AS second sourced? Jean Pierre From ethernut at objenv.com Tue Feb 10 20:32:41 2004 From: ethernut at objenv.com (Rich Wellner) Date: Tue, 10 Feb 2004 13:32:41 -0600 Subject: [En-Nut-Discussion] NutUdpSendTo problem -- follow up (still not working) Message-ID: <871xp2ohly.fsf@objenv.com> Thanks for the tips from yesterday. I've made some changes and still cannot send to the Internet, but can now see packets on my local network. The only thing I have to go on right now is that the gateway may not be getting set properly. Output is below. I don't understand why NutIpRouteAdd returns success but an immediate call to NutIpRouteQuery returns a null NUTDEVICE and ip address of 0. Output: UDP Monitor Daemon, Nut/OS: 3.4.1.1 route: 0 device: 0 Queried: 0.0.0.0 ip: 207.252.251.238 netmask: 255.255.255.248 gateway: 207.252.251.233 dest ip: 216.127.80.16 return: -1 Source: int main(void) { u_long baud = 115200; u_char i; u_long dest_addr; UDPSOCKET *udpsock; /* * Initialize the uart device. */ NutRegisterDevice(&devDebug0, 0, 0); freopen("uart0", "w", stdout); _ioctl(_fileno(stdout), UART_SETSPEED, &baud); NutSleep(200); printf("\n\nUDP Monitor Daemon, Nut/OS: %s\n", NutVersionString()); #ifdef NUTDEBUG NutTraceTcp(stdout, 0); NutTraceOs(stdout, 0); NutTraceHeap(stdout, 0); NutTracePPP(stdout, 0); #endif /* * Register Ethernet controller. */ //if(NutRegisterDevice(&devSmsc111, 0, 0)) if (NutRegisterDevice(&devEth0, 0x8300, 5)) puts("Registering device failed"); u_char mac[] = { MYMAC }; u_long ip_addr = inet_addr(MYIP); u_long ip_mask = inet_addr(MYMASK); NutNetIfConfig("eth0", mac, ip_addr, ip_mask); printf("route: %d\n", NutIpRouteAdd(0, 0, inet_addr("207.252.251.233"), &devEth0)); printf("device: %d\n", NutIpRouteQuery(inet_addr("216.127.80.16"), &ip_addr)); printf("Queried: %s\n", inet_ntoa(ip_addr)); printf("ip: %s\n", inet_ntoa(confnet.cdn_ip_addr)); printf("netmask: %s\n", inet_ntoa(confnet.cdn_ip_mask)); printf("gateway: %s\n", inet_ntoa(confnet.cdn_gateway)); udpsock = NutUdpCreateSocket(0); dest_addr = inet_addr("216.127.80.16"); printf("dest ip: %s\n", inet_ntoa(dest_addr)); /* * We could do something useful here, like serving a watchdog. */ NutThreadSetPriority(254); for (;;) { printf("return: %d\n", NutUdpSendTo(udpsock, dest_addr, 2526, "test", 4)); NutSleep(1000); } } From ethernut at objenv.com Tue Feb 10 23:58:13 2004 From: ethernut at objenv.com (Rich Wellner) Date: Tue, 10 Feb 2004 16:58:13 -0600 Subject: [En-Nut-Discussion] NutUdpSendTo problem -- It's alive! In-Reply-To: <871xp2ohly.fsf@objenv.com> (Rich Wellner's message of "Tue, 10 Feb 2004 13:32:41 -0600") References: <871xp2ohly.fsf@objenv.com> Message-ID: <87n07qmtiy.fsf@objenv.com> Rich Wellner writes: > Thanks for the tips from yesterday. I've made some changes and still cannot > send to the Internet, but can now see packets on my local network. Aha! Oliver sent a private mail with another idea and it turned me in the right direction. His idea was to include a routine to dump more state about the ip stack, but I couldn't get it to compile. I was missing net/route.h from the include list. That file is also where the methods I need to setup my routing live and its absence was the core problem. Once I include that everything works fine. So, thanks to Harald and Oliver for the help, I'm not ready to send packets all over the world and pay closer attention to compiler warnings. rw2 From dferbas at dfsoft.cz Wed Feb 11 01:33:38 2004 From: dferbas at dfsoft.cz (Dusan Ferbas) Date: Wed, 11 Feb 2004 01:33:38 +0100 Subject: [En-Nut-Discussion] GPRS PAP problem Message-ID: <6.0.1.1.2.20040211013022.01d27938@pop3.vol.cz> Hi, I don't have answers for all your question. Just one column. Once the targeting servers confirms no PCOMP and ACOMP during LCP it should stay with it. I experienced only a behaviour that a server was not able to negotiate other than both compress modes off. There were up to 10 attempts with 3 secs intervals and then PPP session was closed by my PPP client. >My real problem is that PAP authentication messages seem to be ignored by my >GPRS server. The server requires a blank username and password. I have >tried blank. I have tried passwords. I have even tried rejecting the >(AUTH=0xC023) request from the server. Still I'm being ignored (except for >the latter where I get a TERMREQ when it is time for IPCP negotiation). >Has anyone experienced this? Could it be that the server is speechless >without PCOMP and ACOMP? Dusan From francois at asnone.com Wed Feb 11 09:14:37 2004 From: francois at asnone.com (Francois Rademeyer) Date: Wed, 11 Feb 2004 10:14:37 +0200 Subject: [En-Nut-Discussion] GPRS PAP problem References: <6.0.1.1.2.20040211013022.01d27938@pop3.vol.cz> Message-ID: <000501c3f077$1a1c42a0$1b00a8c0@sonyfrademeyer> Hi, I resolved the problem by implementing PCOMP and ACOMP in the PPP layer. Seems like my ISP has a sub-standard stack. So much for RFCs. There seems to be so many versions of the NutOS PPP files flying around and I would like to check my changes in. Who is the moderator? Cheers, Francois ----- Original Message ----- From: "Dusan Ferbas" To: Sent: Wednesday, February 11, 2004 2:33 AM Subject: [En-Nut-Discussion] GPRS PAP problem > Hi, > > I don't have answers for all your question. Just one column. Once the > targeting servers confirms no PCOMP and ACOMP during LCP it should stay > with it. > > I experienced only a behaviour that a server was not able to negotiate > other than both compress modes off. There were up to 10 attempts with 3 > secs intervals and then PPP session was closed by my PPP client. > > >My real problem is that PAP authentication messages seem to be ignored by my > >GPRS server. The server requires a blank username and password. I have > >tried blank. I have tried passwords. I have even tried rejecting the > >(AUTH=0xC023) request from the server. Still I'm being ignored (except for > >the latter where I get a TERMREQ when it is time for IPCP negotiation). > >Has anyone experienced this? Could it be that the server is speechless > >without PCOMP and ACOMP? > > Dusan > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From harald.kipp at egnite.de Wed Feb 11 09:21:07 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 11 Feb 2004 09:21:07 +0100 Subject: [En-Nut-Discussion] GPRS PAP problem In-Reply-To: <000501c3f077$1a1c42a0$1b00a8c0@sonyfrademeyer> References: <6.0.1.1.2.20040211013022.01d27938@pop3.vol.cz> Message-ID: <5.1.1.6.0.20040211092009.02ccfeb0@egnite.de> Francois, Please send all PPP related changes to me harald at egnite dot de. Thanks From harald.kipp at egnite.de Wed Feb 11 09:43:11 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 11 Feb 2004 09:43:11 +0100 Subject: [En-Nut-Discussion] NutUdpSendTo problem -- It's alive! In-Reply-To: <87n07qmtiy.fsf@objenv.com> References: <871xp2ohly.fsf@objenv.com> <871xp2ohly.fsf@objenv.com> Message-ID: <5.1.1.6.0.20040211093229.02ae6cb8@egnite.de> Rich, good you solved the problem. I'm very sensitive to compiler warnings. The complete source should compile without any warning. 'make > mk.log' should not produce any output. Ted added a compiler option for treating warnings as errors, but I removed this. I thoght, it's a bit too drastic. Regards, Harald P.S.: Oliver, can you please add a final linefeed to the last line of irqstack.h. At least with GCC 3.5 this produces a warning. From enut at ixo.de Wed Feb 11 13:20:42 2004 From: enut at ixo.de (Waschk,Kolja) Date: Wed, 11 Feb 2004 13:20:42 +0100 (CET) Subject: [En-Nut-Discussion] Problem with CPU clock freq computation Message-ID: Hi On a selfmade board similar to the Ethernut 1, I experience a weird effect involving NutComputeCpuClock(). The computed cpu_clock is 12287200 Hz, which is almost exactly 5/6 of 14,745600 MHz. Actually we use a 14,7456 MHz crystal. The clock crystal has the usual 32,768 kHz. Measurements proved that the actual clocks ARE 14,745600 MHz resp. 32,768 kHz. Then, e.g. UART baud rate is only correctly set up if CPU clock freq of 14,7456 MHz was hardcoded (e.g. using -DNUT_CPU_FREQ=14745600). Did anyone had some similar effect in the past and has an explanation for me? Fuses of the m128 are set to 0xFF 0x03 0x3F, i.e. longest startup time. Pausing the m128 just before NutComputeCpuClock (via JTAG) doesn't have any effect on the outcome of the computation. It always yields 12287200. I'm using gcc 3.3.2, BTW. The most "visible" difference to the Ethernut 1.3F is that we're using a 32,768 kHz crystal in SMD package. But as I said above, the actual clock looks correct when measured with external equipment. Thanks for hints in advance Kolja -- mr. kolja waschk - haubach-39 - 22765 hh - ger phone +49 40 889130-34 - fax -35 - e-mail s.a. From bbuenaobra at nip.upd.edu.ph Thu Feb 12 05:25:58 2004 From: bbuenaobra at nip.upd.edu.ph (Berns J. Buenaobra) Date: Wed, 11 Feb 2004 20:25:58 -0800 Subject: [En-Nut-Discussion] Re: [En-Nut-Announce] Webport Application Update References: <5.1.1.6.0.20040210182907.0330e920@egnite.de> Message-ID: <001e01c3f120$510b5310$6565a8c0@instru.nip.upd.edu.ph> This is indeed wonderful news! Exciting to me and my co-workers at the lab! 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-920-5474 Mobile: 0916-255-0056 URL: www.nip.upd.edu.ph/ipl *************************************** ----- Original Message ----- From: "Harald Kipp" To: Sent: Tuesday, February 10, 2004 9:32 AM Subject: [En-Nut-Announce] Webport Application Update > The Webport application sample > http://www.ethernut.de/app/webport/index.html > > has been ported to Nut/OS 3.x > http://www.ethernut.de/arc/webp201.zip > > Enjoy, > Harald Kipp > > > _______________________________________________ > En-Nut-Announce mailing list > En-Nut-Announce at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-announce > From 021243 at student.hit.no Wed Feb 11 13:50:36 2004 From: 021243 at student.hit.no (Sigurd Kleppan) Date: Wed, 11 Feb 2004 13:50:36 +0100 Subject: [En-Nut-Discussion] DS1620 temp sensor Message-ID: In my project with Ethernut i want to log som temperatures. I use DS1620 and to get the temp. I have to send 0xAA to the device. Then i get the temp back. I have written a code to send the data, but it is not working. Can you see some error and give me some hints on whats wrong in the Get1620byte and Put1620byte functions please. Do you know someone who have written code for DS1620 i Ethernut? Thank you! Sigurd //THE TEMPERATURE CODE unsigned char Get1620byte( void ) { unsigned char j,k=0,b=1; outp(0x00,DDRB); outp(0x00,PORTB); for (j=0; j<8; j++) { cbi(PORTB,0); //CLK=0; if (bit_is_set(PINB, 3)){ k|=b;} sbi(PORTB,0); //CLK=1; b=(b<<1); /* Setup for next read and or */ } cbi(PORTB,0); cbi(PORTB,3); return k; } unsigned char Put1620byte(unsigned char m) { unsigned char k,b=1; unsigned char DQ; outp(0xFF,DDRB); cbi(PORTB,0); cbi(PORTB,3); sbi(PORTB,5); //RST=1; for (k=0; k<8; k++) { cbi(PORTB,0); //CLK=0; DQ[k] = (m & b); if(!DQ==0){ sbi(PORTB,3);} else{cbi(PORTB,3);} sbi(PORTB,0); //CLK=1; b=(b<<1); /* Setup to send next bit */ } cbi(PORTB,0); cbi(PORTB,3); return 0; } void main(){ sbi(PORTB,5); // RST=1; Put1620byte(0xAA)); temp_and_half_bit = Get1620byte(); /* read 1st byte of temp */ sign_bit = Get1620byte(); /* read 2nd byte of temp */ cbi(PORTB,5); fprintf(stream,"%d",temp_and_half_bit); } From conorduke at yahoo.co.uk Wed Feb 11 14:51:28 2004 From: conorduke at yahoo.co.uk (=?iso-8859-1?q?Conor=20Duke?=) Date: Wed, 11 Feb 2004 13:51:28 +0000 (GMT) Subject: [En-Nut-Discussion] RE:NIC reset Failed Message-ID: <20040211135128.78992.qmail@web25002.mail.ukl.yahoo.com> Hey, Newbie problem ,please bear with me as i'm sure the solution is quite simple. Everything was working fine i have set up a http server that was monitoring a plc controller but when i began to try and setup LED's on the expansion port .The ethernet connection stopped working. so i loaded the HTTPserver demo and i got no response then i loaded BASEMON and recieved the following ; NIC hardware reset...failed Trying NIC software reset...failed NIC id detection... failed, got 0x0A0B, expected 0x5070 NIC hardware reset...failed Trying NIC software reset...failed NIC id detection... failed, got 0x0A0B, expected 0x5070 I/O Port Test... PORTE bits FC I read a similar post to with the exact same problem but no1 replied so i am assuming ther is an easy way to solve it ,but my thesis is due in 2 weeks so i need the EASY way out unfortunatly. Do i need a new chip or can i fix it on my own, Any help would be greatly appriciated Yours in Eternal Gratitude Regards Conor --------------------------------- BT Yahoo! Broadband - Free modem offer, sign up online today and save ?80 -------------- next part -------------- An HTML attachment was scrubbed... URL: From harald.kipp at egnite.de Wed Feb 11 19:41:58 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 11 Feb 2004 19:41:58 +0100 Subject: [En-Nut-Discussion] Problem with CPU clock freq computation In-Reply-To: Message-ID: <5.1.1.6.0.20040211193556.031e86e8@egnite.de> Kolja, >Fuses of the m128 are set to 0xFF 0x03 0x3F, i.e. longest startup time. Nothing around here right now to check the fuses, but I guess this differs. Did you set CKOPT? We never experienced this problem. If you measured correct frequencies, there must be another difference, I'm sure. Harald From harald.kipp at egnite.de Wed Feb 11 20:02:54 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 11 Feb 2004 20:02:54 +0100 Subject: [En-Nut-Discussion] RE:NIC reset Failed In-Reply-To: <20040211135128.78992.qmail@web25002.mail.ukl.yahoo.com> Message-ID: <5.1.1.6.0.20040211194819.032a7758@egnite.de> Hi Conor, the only post I can find was from Gert Jan Kruizinga, about one year ago. He was part of the robot contest team and I later heard from Peter Kunst, that they had indeed two boards broken. Specially the RTL8019AS is very sensitive to ESD and in the first place of chips getting effected. Second is the ATmega, as you can imagine. You didn't change anything else? Power supply? Add on board? Try to put everything in it's initial status and use Basemon to check the board. Please also post the full basemon report including version banner to info at egnite dot de. >I read a similar post to with the exact same problem but no1 replied so i >am assuming ther is an easy way to solve it ,but my thesis is due in 2 >weeks so i need the EASY way out unfortunatly. This sounds familiar and made my name entered here :-) http://innovexpo.itee.uq.edu.au/2003/exhibits/s354335/thesis.pdf Toby had been in the same situation, but he was in Queensland, 2 shipping weeks away...and we get it done. So don't worry. >Do i need a new chip or can i fix it on my own, Not recommended. We replace ATmegas, Realteks and SMSC from time to time...just for fun and training. It usually fails, if you do not own very expensive hot air equipment. The 2000 US$ irons are _not_ the expensive ones. I'll contact you by private email. Harald From dferbas at dfsoft.cz Thu Feb 12 12:26:56 2004 From: dferbas at dfsoft.cz (Dusan Ferbas) Date: Thu, 12 Feb 2004 12:26:56 +0100 Subject: [En-Nut-Discussion] DS1620 temp sensor Message-ID: <6.0.1.1.2.20040212121919.01cc61f0@pop3.vol.cz> Hi, insert required delays into main(). Follow AC characteristics and waveforms from Maxim's datasheet. E.g. in Put1620byte() you have DQ[k] ! There are application notes at Maxim's site. >In my project with Ethernut i want to log som temperatures. I use DS1620 >and to get the temp. I have to send 0xAA to the device. Then i get the >temp back. >I have written a code to send the data, but it is not working. Can you see >some error and give me some hints on whats wrong in the Get1620byte and >Put1620byte functions please. Dusan From rsloan2003 at hotmail.com Thu Feb 12 20:07:40 2004 From: rsloan2003 at hotmail.com (Richard Sloan) Date: Thu, 12 Feb 2004 14:07:40 -0500 Subject: [En-Nut-Discussion] IDE interface Message-ID: Search the archives unsuccessfully for this info. What is the current stage of the IDE interface with a CPLD? I would be interested to help if I could, I have done lots of disk interfacing before. Richard. _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca From enut at ixo.de Thu Feb 12 20:30:38 2004 From: enut at ixo.de (Waschk,Kolja) Date: Thu, 12 Feb 2004 20:30:38 +0100 (CET) Subject: [En-Nut-Discussion] Problem with CPU clock freq computation In-Reply-To: <5.1.1.6.0.20040211193556.031e86e8@egnite.de> References: <5.1.1.6.0.20040211193556.031e86e8@egnite.de> Message-ID: > >Fuses of the m128 are set to 0xFF 0x03 0x3F, i.e. longest startup time. > fuses, but I guess this differs. Did you set CKOPT? Yep, and it's all right now. There have been a couple of other problems, and the output on my terminal looked perfectly as if the UART ran at a slightly wrong clock... but it turned out to be just the terminal: Garbage that comes from the m128 while flashing (via JTAG) somehow changes the charset encoding configuration for the output... > We never experienced this problem. If you > measured correct frequencies, there must be > another difference, I'm sure. There's still the confusing outcome of the NutComputeCpuClock() of 12,288 Mhz; I'll take a closer look at this issue in the coming days. Maybe I currently just misinterpret the value, or compilation without optimization resulted in a longer loop body (and thus smaller count). Our m128 definitely runs at 14,7456 MHz. If I remain quiet about this within the next days, please regard the "problem" as void :) I now have our boards completely up and running. They differ from the Ethernut1 only slightly, with 64kB RAM and the RTL8019AS "in parallel". A single I/O from m128 selects between RAM and RTL, driven by code added in nicrtl.c. However I don't think it's of general use (the upper 32kB of RAM are not used as heap but for interfacing to a host only), but if anyone is interested I'd prepare a patch for integration in CVS. Kolja -- mr. kolja waschk - haubach-39 - 22765 hh - ger phone +49 40 889130-34 - fax -35 - e-mail s.a. From enut at ixo.de Thu Feb 12 20:44:01 2004 From: enut at ixo.de (Waschk,Kolja) Date: Thu, 12 Feb 2004 20:44:01 +0100 (CET) Subject: [En-Nut-Discussion] Interrupting NutTcpSend/Receive from other thread Message-ID: Hi.. I wonder what is the "best" method to force disconnection of a TCP socket from one thread, while other threads are currently blocking on a NutTcpSend or -Receive on that socket? I could use some global flag indicating the disconnection request and "manually" post an event on the socket's so_tx_tq/so_rx_tq to wake up the other threads... Is there a better method? Kolja -- mr. kolja waschk - haubach-39 - 22765 hh - ger phone +49 40 889130-34 - fax -35 - e-mail s.a. From fischermi at t-online.de Thu Feb 12 20:58:47 2004 From: fischermi at t-online.de (Michael Fischer) Date: Thu, 12 Feb 2004 20:58:47 +0100 Subject: [En-Nut-Discussion] IDE interface Message-ID: Hello Richard, The prototype is working. But Harald has the idee to bring the CF and IDE interface togehter. Therefore I think it takes a little bit more time to produce a PCB. The problem is the CF interface, because it should support a card which is using the WAIT signal. Therefore we need a state machine in the CPLD. But we are working on it. The other problem is the voltage. The ide interface is a 5 volt interface, but the cf card should support 3.3 volt cards. Therfore we need a level shifter on the board too. I think Harald could give some more information about the estimated time to have a PCB. Harald, now its your part :-) Regards, Michael From fischermi at t-online.de Thu Feb 12 21:04:37 2004 From: fischermi at t-online.de (Michael Fischer) Date: Thu, 12 Feb 2004 21:04:37 +0100 Subject: [En-Nut-Discussion] IDE interface Message-ID: Richard, I think it could be a good idee, that you can check our interface? Are you familiar with the programming too? I have the problem if I connect 2 IDE devices like a hard disk and a cd rom, or two disk. The software supports now: - hard disk - cd rom - zip drive (100MB) - cf cards But in the moment only the read functionality. Michael From harald.kipp at egnite.de Thu Feb 12 21:04:52 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Thu, 12 Feb 2004 21:04:52 +0100 Subject: [En-Nut-Discussion] Interrupting NutTcpSend/Receive from other thread In-Reply-To: Message-ID: <5.1.1.6.0.20040212210336.0323bd50@egnite.de> NutTcpCloseSocket? From harald.kipp at egnite.de Thu Feb 12 21:15:12 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Thu, 12 Feb 2004 21:15:12 +0100 Subject: [En-Nut-Discussion] IDE interface In-Reply-To: Message-ID: <5.1.1.6.0.20040212210514.0323abb8@egnite.de> > >Harald, now its your part :-) Sigh! I know, I know.... After intensively checking interface requirements and drivers, I finally ended up with 74LVT16244/245 for both CF and IDE and a XC95144XL CPLD. Perhaps the CPLD is a bit oversized...but we do not know yet what might be required to handle the CF card's wait signal in a fancy way. Ah, yes, and I finally dropped the idea of supporting 5V CF cards. Harald From rsloan2003 at hotmail.com Thu Feb 12 21:28:51 2004 From: rsloan2003 at hotmail.com (Richard Sloan) Date: Thu, 12 Feb 2004 15:28:51 -0500 Subject: [En-Nut-Discussion] IDE interface Message-ID: Yes you do not need to support 5V only CF! Everything out there will usually work on both as there is a signal on the CF card to tell 3.3 or 5V Wait signal, I never used this before.... I will need to look this one up, I have only read CF cards and not wrote, so maybe WAIT is only for writes? Is there any schematics etc? I could look at and verify for you? Richard. >From: Harald Kipp >Reply-To: "Ethernut User Chat (English)" >To: "Ethernut User Chat (English)" >Subject: Re: [En-Nut-Discussion] IDE interface >Date: Thu, 12 Feb 2004 21:15:12 +0100 > > >> >>Harald, now its your part :-) > >Sigh! I know, I know.... > >After intensively checking interface requirements and >drivers, I finally ended up with 74LVT16244/245 for >both CF and IDE and a XC95144XL CPLD. > >Perhaps the CPLD is a bit oversized...but we do not >know yet what might be required to handle the CF card's >wait signal in a fancy way. > >Ah, yes, and I finally dropped the idea of supporting >5V CF cards. > >Harald > >_______________________________________________ >En-Nut-Discussion mailing list >En-Nut-Discussion at egnite.de >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/photos&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca From rsloan2003 at hotmail.com Thu Feb 12 21:29:54 2004 From: rsloan2003 at hotmail.com (Richard Sloan) Date: Thu, 12 Feb 2004 15:29:54 -0500 Subject: [En-Nut-Discussion] IDE interface Message-ID: Thanks! What is status on FAT16/32 writes? Richard. >From: fischermi at t-online.de (Michael Fischer) >Reply-To: "Ethernut User Chat (English)" >To: >Subject: [En-Nut-Discussion] IDE interface >Date: Thu, 12 Feb 2004 21:04:37 +0100 > >Richard, > >I think it could be a good idee, >that you can check our interface? > >Are you familiar with the programming too? >I have the problem if I connect 2 IDE devices like a hard disk and a cd >rom, >or two disk. The software supports now: > >- hard disk >- cd rom >- zip drive (100MB) >- cf cards > >But in the moment only the read functionality. > >Michael > > >_______________________________________________ >En-Nut-Discussion mailing list >En-Nut-Discussion at egnite.de >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca From rsloan2003 at hotmail.com Thu Feb 12 21:32:41 2004 From: rsloan2003 at hotmail.com (Richard Sloan) Date: Thu, 12 Feb 2004 15:32:41 -0500 Subject: [En-Nut-Discussion] IDE interface Message-ID: Have you also done any thinking of also supporting WLAN WiFI type CF cards on the same interface too? :-) Are these cards like IDE interface or memory interface... any word on this? Richard. >From: Harald Kipp >Reply-To: "Ethernut User Chat (English)" >To: "Ethernut User Chat (English)" >Subject: Re: [En-Nut-Discussion] IDE interface >Date: Thu, 12 Feb 2004 21:15:12 +0100 > > >> >>Harald, now its your part :-) > >Sigh! I know, I know.... > >After intensively checking interface requirements and >drivers, I finally ended up with 74LVT16244/245 for >both CF and IDE and a XC95144XL CPLD. > >Perhaps the CPLD is a bit oversized...but we do not >know yet what might be required to handle the CF card's >wait signal in a fancy way. > >Ah, yes, and I finally dropped the idea of supporting >5V CF cards. > >Harald > >_______________________________________________ >En-Nut-Discussion mailing list >En-Nut-Discussion at egnite.de >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From kyle at ghbraille.com Thu Feb 12 21:35:39 2004 From: kyle at ghbraille.com (Kyle Rhodes) Date: Thu, 12 Feb 2004 15:35:39 -0500 Subject: [En-Nut-Discussion] IDE interface Message-ID: <0966F93C53C483498BEE4F695383DCF0108450@fs01.ghbraille.com> Has anyone looked into the Atmel AVR IDE board that http://www.edtp.com sells? I suggest downloading the archive for the board and looking at the code. I believe it supports "AVR DOS", so I assume at least FAT16 is implemented. I also read something about CF support. Kyle Rhodes Hardware / Software Engineer gh, LLC 3000 Kent Ave Lafayette, IN 47906 (765) 775-3776 ext 205 -----Original Message----- From: Richard Sloan [mailto:rsloan2003 at hotmail.com] Sent: Thursday, February 12, 2004 3:30 PM To: en-nut-discussion at egnite.de Subject: RE: [En-Nut-Discussion] IDE interface Thanks! What is status on FAT16/32 writes? Richard. >From: fischermi at t-online.de (Michael Fischer) >Reply-To: "Ethernut User Chat (English)" >To: >Subject: [En-Nut-Discussion] IDE interface >Date: Thu, 12 Feb 2004 21:04:37 +0100 > >Richard, > >I think it could be a good idee, >that you can check our interface? > >Are you familiar with the programming too? >I have the problem if I connect 2 IDE devices like a hard disk and a cd >rom, >or two disk. The software supports now: > >- hard disk >- cd rom >- zip drive (100MB) >- cf cards > >But in the moment only the read functionality. > >Michael > > >_______________________________________________ >En-Nut-Discussion mailing list >En-Nut-Discussion at egnite.de >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin .msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From jesperh at telia.com Thu Feb 12 21:36:06 2004 From: jesperh at telia.com (Jesper Hansen) Date: Thu, 12 Feb 2004 21:36:06 +0100 Subject: [En-Nut-Discussion] IDE interface References: Message-ID: <070b01c3f1a7$da013310$6500a8c0@jeha> The WLAN cards cannot be compared to IDE interface as the register layout is completely different. Also, they only seem to work in I/O mode. /Jesper ----- Original Message ----- From: "Richard Sloan" To: Sent: Thursday, February 12, 2004 9:32 PM Subject: Re: [En-Nut-Discussion] IDE interface > Have you also done any thinking of also supporting WLAN WiFI type CF cards > on the same interface too? :-) > > Are these cards like IDE interface or memory interface... any word on this? > > Richard. > > > >From: Harald Kipp > >Reply-To: "Ethernut User Chat (English)" > >To: "Ethernut User Chat (English)" > >Subject: Re: [En-Nut-Discussion] IDE interface > >Date: Thu, 12 Feb 2004 21:15:12 +0100 > > > > > >> > >>Harald, now its your part :-) > > > >Sigh! I know, I know.... > > > >After intensively checking interface requirements and > >drivers, I finally ended up with 74LVT16244/245 for > >both CF and IDE and a XC95144XL CPLD. > > > >Perhaps the CPLD is a bit oversized...but we do not > >know yet what might be required to handle the CF card's > >wait signal in a fancy way. > > > >Ah, yes, and I finally dropped the idea of supporting > >5V CF cards. > > > >Harald > > > >_______________________________________________ > >En-Nut-Discussion mailing list > >En-Nut-Discussion at egnite.de > >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > _________________________________________________________________ > Protect your PC - get McAfee.com VirusScan Online > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From rsloan2003 at hotmail.com Thu Feb 12 21:57:26 2004 From: rsloan2003 at hotmail.com (Richard Sloan) Date: Thu, 12 Feb 2004 15:57:26 -0500 Subject: [En-Nut-Discussion] IDE interface Message-ID: Ya thats what I meant... I think.... I/O mode or Memory Mode. Cool! >From: "Jesper Hansen" >Reply-To: "Ethernut User Chat (English)" >To: "Ethernut User Chat (English)" >Subject: Re: [En-Nut-Discussion] IDE interface >Date: Thu, 12 Feb 2004 21:36:06 +0100 > >The WLAN cards cannot be compared to IDE interface as the register layout >is completely different. >Also, they only seem to work in I/O mode. > >/Jesper > >----- Original Message ----- >From: "Richard Sloan" >To: >Sent: Thursday, February 12, 2004 9:32 PM >Subject: Re: [En-Nut-Discussion] IDE interface > > > > Have you also done any thinking of also supporting WLAN WiFI type CF >cards > > on the same interface too? :-) > > > > Are these cards like IDE interface or memory interface... any word on >this? > > > > Richard. > > > > > > >From: Harald Kipp > > >Reply-To: "Ethernut User Chat (English)" > > >To: "Ethernut User Chat (English)" > > >Subject: Re: [En-Nut-Discussion] IDE interface > > >Date: Thu, 12 Feb 2004 21:15:12 +0100 > > > > > > > > >> > > >>Harald, now its your part :-) > > > > > >Sigh! I know, I know.... > > > > > >After intensively checking interface requirements and > > >drivers, I finally ended up with 74LVT16244/245 for > > >both CF and IDE and a XC95144XL CPLD. > > > > > >Perhaps the CPLD is a bit oversized...but we do not > > >know yet what might be required to handle the CF card's > > >wait signal in a fancy way. > > > > > >Ah, yes, and I finally dropped the idea of supporting > > >5V CF cards. > > > > > >Harald > > > > > >_______________________________________________ > > >En-Nut-Discussion mailing list > > >En-Nut-Discussion at egnite.de > > >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > > > _________________________________________________________________ > > Protect your PC - get McAfee.com VirusScan Online > > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > >_______________________________________________ >En-Nut-Discussion mailing list >En-Nut-Discussion at egnite.de >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From fischermi at t-online.de Thu Feb 12 22:12:00 2004 From: fischermi at t-online.de (Michael Fischer) Date: Thu, 12 Feb 2004 22:12:00 +0100 Subject: [En-Nut-Discussion] IDE interface Message-ID: Richard, WLAN: This is the problem. The WLAN card use the WAIT signal, for both, IORD and IOWR. In the moment I work with a "bus emulation". Some latch to emulate the bus access, but this takes about 1.5us .. 2us. I have measured the WAIT, on my notebook, and found waits up to 300ns. A full access CE was up to 600ns. The atmega is to fast. Without the emulation, it is possible to use the XDIV functionality of the CPU, and divide the clock to a lower access. I think this is not a good solution. Take a look in the Ethernut CF (WLAN) Interface thread. WRITE function: In the moment on hold, I am waiting on a PCB, Harald? You will find the source by Ethernut. Jesper: How is your "April Fool" working? Michael From enut at ixo.de Thu Feb 12 22:43:19 2004 From: enut at ixo.de (Waschk,Kolja) Date: Thu, 12 Feb 2004 22:43:19 +0100 (CET) Subject: [En-Nut-Discussion] Interrupting NutTcpSend/Receive from other thread In-Reply-To: <5.1.1.6.0.20040212210336.0323bd50@egnite.de> References: <5.1.1.6.0.20040212210336.0323bd50@egnite.de> Message-ID: > NutTcpCloseSocket? Almost, but that doesn't relieve me from notifying the threads blocking on NutTcpSend/Receive, does it? Ah, that may happen later automatically when NutTcpStateCloseEvent initiates NutTcpStateChange etc... Okay, I probably was (or am) blinded by the API documentation bit that says "the application must not use the socket after this call." (but *during* the call it maybe is allowed to do...) I'll try. Thanks; Kolja -- mr. kolja waschk - haubach-39 - 22765 hh - ger phone +49 40 889130-34 - fax -35 - e-mail s.a. From jesperh at telia.com Thu Feb 12 22:52:45 2004 From: jesperh at telia.com (Jesper Hansen) Date: Thu, 12 Feb 2004 22:52:45 +0100 Subject: [En-Nut-Discussion] IDE interface References: Message-ID: <072701c3f1b2$92364a10$6500a8c0@jeha> Looking at the Intersil documentation for the HFA3842 (used in D-Link DCF-660 and Netgear MA701), they state a max WAIT of 12.000 nS !! In my port I/O based version, I've been using 6 nops (at 7.37 MHz), which seems to be enough. A bit difficult to say for sure though, but I've transferred a number of files forth and back without problems. I tried using the XDIV, but that upset the UART so it got completely confused and sent (and received) erroneous data. It would also upset any other timing of course. I find the port I/O solution quite okay. It uses about 18-20 cycles (2.6uS), which is not too bad. But interrupts needs to be disabled as I'm disabling the external memory interface during the card access. My April's fool is working pretty well, although not exactly as shown ;-) Just wait until you see this years version !! /Jesper ----- Original Message ----- From: "Michael Fischer" To: Sent: Thursday, February 12, 2004 10:12 PM Subject: [En-Nut-Discussion] IDE interface > Richard, > > WLAN: This is the problem. The WLAN card use the WAIT signal, for both, IORD > and IOWR. > In the moment I work with a "bus emulation". Some latch to emulate the bus > access, but this takes > about 1.5us .. 2us. > > I have measured the WAIT, on my notebook, and found waits up to 300ns. A > full access CE was up to 600ns. > The atmega is to fast. Without the emulation, it is possible to use the XDIV > functionality of the CPU, > and divide the clock to a lower access. I think this is not a good solution. > > Take a look in the Ethernut CF (WLAN) Interface thread. > > WRITE function: > In the moment on hold, I am waiting on a PCB, Harald? > You will find the source by Ethernut. > > Jesper: > > How is your "April Fool" working? > > Michael > > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From mikec at call-direct.com.au Wed Feb 11 02:48:21 2004 From: mikec at call-direct.com.au (Mike Cornelius) Date: Wed, 11 Feb 2004 12:48:21 +1100 Subject: [En-Nut-Discussion] GPRS PAP problem In-Reply-To: <01c101c3ef25$0a7a6e10$1000a8c0@sonyfrademeyer> Message-ID: <00db01c3f041$222cfce0$2301a8c0@Mike> That's odd, what type of GPRS module are you using? Do you have the APN set correctly ("at+cgdcont") ? I am familiar with the Ericsson GM47 and Nokia 30 modems. Both of these won't start PPP unless the APN is correct. It is of course possible that your module behaves differently. Also with GPRS the PPP session is only between your application and the GPRS module itself (ie the module is the server, the PPP negotiation is NOT done over the air). Most modules (that I've used) will not reject a PPP session at authentication time they simply accept the supplied username and password, and always return OK. Later on once IPCP negotiation begins the module sends both the authentication details and IPCP request to the network at the same time. However I'm not exactly sure of the details of the GPRS side of things (in particular what things MUST the module know before it can start the GPRS authintication phase). The server (module) ACK's your rejection of PCOMP/ACOMP (ie LCP completes) so that doesn't look like the problem to me. 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-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Francois Rademeyer Sent: Tuesday, February 10, 2004 2:55 AM To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] GPRS PAP problem Hi all, Firstly there seems to be a bug in the latest "lcpout.c" file. The line : if ((nb = NutNetBufAlloc(0, NBAF_APPLICATION, rejected ? 6 : 12)) != 0) { should be: if ((nb = NutNetBufAlloc(0, NBAF_APPLICATION, rejected ? 12 : 6)) != 0) { My real problem is that PAP authentication messages seem to be ignored by my GPRS server. The server requires a blank username and password. I have tried blank. I have tried passwords. I have even tried rejecting the (AUTH=0xC023) request from the server. Still I'm being ignored (except for the latter where I get a TERMREQ when it is time for IPCP negotiation). Has anyone experienced this? Could it be that the server is speechless without PCOMP and ACOMP? Thanks in advance for any help. Cheers, Francois Rademeyer Here is a shortened version of my PPP debug output for a blank id/password: PPP < [LCP-1 CONFREQ (ACCM = 0x000A000)] PPP > [LCP-1 CONFREQ (MRU=1500)(ACCM = 0x0000000)(PCOMP)(ACOMP)(AUTH=0xC023)] PPP < [LCP-1 CONFREJ (PCOMP)(ACOMP)] PPP > [LCP-1 CONFACK (ACCM = 0x000A000)] PPP > [LCP-2 CONFREQ (MRU=1500)(ACCM = 0x0000000)(AUTH=0xC023)] PPP < [LCP-2 CONFACK (MRU=1500)(ACCM = 0x0000000)(AUTH=0xC023)] PPP < [PAP-3 AUTHREQ] ... 5 second delay PPP < [PAP-3 AUTHREQ] ... 5 second delay PPP < [PAP-3 AUTHREQ] ... 5 second delay PPP < [PAP-3 AUTHREQ] ... 5 second delay PPP < [PAP-3 AUTHREQ] ... 5 second delay PPP < [PAP-3 AUTHREQ] ... no auth reply received (timeout) -------------- next part -------------- An HTML attachment was scrubbed... URL: From harald.kipp at egnite.de Fri Feb 13 15:14:17 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Fri, 13 Feb 2004 15:14:17 +0100 Subject: [En-Nut-Discussion] Interrupting NutTcpSend/Receive from other thread In-Reply-To: References: <5.1.1.6.0.20040212210336.0323bd50@egnite.de> <5.1.1.6.0.20040212210336.0323bd50@egnite.de> Message-ID: <5.1.1.6.0.20040213150815.032dbde8@egnite.de> At 22:43 12.02.2004 +0100, you wrote: > > NutTcpCloseSocket? > >Almost, but that doesn't relieve me from notifying the threads blocking >on NutTcpSend/Receive, does it? Ah, that may happen later automatically If it works as intended, the close will broadcast an event to all waiting threads. But not fully sure after later mods done to these part. Some waiting loops may reenter the NutEventWait, if the action (characters received, connection established) didn't happen. These loops should check the socket status and quit the loop, if it's not in established state. If it fails, we should correct the loops. Generally calling NutTcpCloseSocket() is the correct way to terminate the receiver thread, IMHO. Harald From harald.kipp at egnite.de Fri Feb 13 15:30:53 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Fri, 13 Feb 2004 15:30:53 +0100 Subject: [En-Nut-Discussion] Improved RTL8019AS Driver Message-ID: <5.1.1.6.0.20040213152350.0346c1c0@egnite.de> Bengt Florin contributed an improved Ethernet driver for the Realtek chip. It's available for download here: http://www.ethernut.de/en/projects.html I didn't commit it to CVS now, because it's a kind of basic function and may introduce really weird problems. Please report, if this works for you. I'll also check it here and commit it then. Many thanks to Bent for this time consuming work. I know what I'm talking about. The RTL is a really picky chip and consumed days of my live. Harald From damian at commtech.com.au Mon Feb 16 05:28:34 2004 From: damian at commtech.com.au (Damian Slee) Date: Mon, 16 Feb 2004 12:28:34 +0800 Subject: [En-Nut-Discussion] Improved RTL8019AS Driver Message-ID: Working here with ping -l 60000, whereas the old was rebooting at about ping -l 6500. Have also got latest CVS. Adding a couple of features to our configuration, so will report back in a week after this and the new driver have had some testing. -----Original Message----- From: Harald Kipp [mailto:harald.kipp at egnite.de] Sent: Friday, 13 February 2004 10:31 PM To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] Improved RTL8019AS Driver Bengt Florin contributed an improved Ethernet driver for the Realtek chip. It's available for download here: http://www.ethernut.de/en/projects.html I didn't commit it to CVS now, because it's a kind of basic function and may introduce really weird problems. Please report, if this works for you. I'll also check it here and commit it then. Many thanks to Bent for this time consuming work. I know what I'm talking about. The RTL is a really picky chip and consumed days of my live. Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From damian at commtech.com.au Mon Feb 16 09:15:32 2004 From: damian at commtech.com.au (Damian Slee) Date: Mon, 16 Feb 2004 16:15:32 +0800 Subject: [En-Nut-Discussion] Uart and flow control Message-ID: Hi all, Should uartavr.h be used or usartavr.h for RTS/CTS flow control or XON/XOFF. Usartavr looks more complete, but how do I open that device? I use this for Uart1; NutRegisterDevice(&devUart1, 0, 0); g_rs232 = fopen("uart1", "r+b"); fileno = _fileno(g_rs232); I notice the code in uartavr.c has this, which is obviosly wrong. Look like a copyn'paste from UART_SETLOCALECHO. case UART_SETFLOWCONTROL: if (bv) dcb->dcb_modeflags |= UART_MF_LOCALECHO; else dcb->dcb_modeflags &= ~UART_MF_LOCALECHO; break; case UART_GETFLOWCONTROL: break; Thanks, damian From enut at ixo.de Mon Feb 16 20:33:27 2004 From: enut at ixo.de (Waschk,Kolja) Date: Mon, 16 Feb 2004 20:33:27 +0100 (CET) Subject: [En-Nut-Discussion] Problem with Timers Message-ID: Hi I'm currently hunting for anything that is causing "almost deterministic" lockups of my target. In that state it won't even answer ICMP echo reqs. When interrupted (with avr-gdb / JTAG), gdb most of the time says the interruption occured during NutTimerInsert or some other code in my app that internally is going to use a timer (NutEventWait or similar). So I'm peeking aroung the timer data and code. What I'm wondering is the nutTimerList gdb presents me. Is it okay if it contains self-referencing items, i.e. where tnp == tnp->tn_next? After I put in a real dirty hack to cancel exactly this situation, it came up with referencing loops like shown here: Program received signal SIGINT, Interrupt. 0x0000aa56 in NutTimerInsert (tn=0x80317c) at timer.c:169 169 if (tn->tn_ticks_left < tnp->tn_ticks_left) { (gdb) print tnp $1 = (NUTTIMERINFO *) 0x801825 (gdb) print tnp->tn_next $2 = (NUTTIMERINFO *) 0x80317c (gdb) print tnp->tn_next->tn_next $3 = (NUTTIMERINFO *) 0x801825 (note: same as $1) (gdb) print tnp->tn_next->tn_next->tn_next $4 = (NUTTIMERINFO *) 0x80317c (naturally, same as $2) BTW, saying "almost deterministic" just means that it almost always occurs at about the same time after starting a certain test procedure that causes quite a lot of activity. That's about 5 minutes however. Only a few times it occured a lot earlier. Kolja -- mr. kolja waschk - haubach-39 - 22765 hh - ger phone +49 40 889130-34 - fax -35 - e-mail s.a. From ralph.mason at telogis.com Tue Feb 17 00:00:20 2004 From: ralph.mason at telogis.com (Ralph Mason) Date: Tue, 17 Feb 2004 12:00:20 +1300 Subject: [En-Nut-Discussion] Announce: Nut Hardware Message-ID: <40314B84.4060505@telogis.com> I am pleased to announce new nut compatible hardware. Details from: http://telogis.com/oem_datasheet.pdf It is aimed at telematics applications for OEM's and integrators. The hardware has quite a few nice features, and many NutOS enhancements to support the hardware. It also includes the fabled window simulator. It is shipping now in volume. Regards Ralph From rsloan2003 at hotmail.com Tue Feb 17 05:54:07 2004 From: rsloan2003 at hotmail.com (Richard Sloan) Date: Mon, 16 Feb 2004 23:54:07 -0500 Subject: [En-Nut-Discussion] CPLD equations Message-ID: Does anyone have the CPLD equations/design? I see a schematic to download but its not the guts of the CPLD! Thanks! >From: Ralph Mason >Reply-To: "Ethernut User Chat (English)" >To: en-Nut-Discussion >Subject: [En-Nut-Discussion] Announce: Nut Hardware >Date: Tue, 17 Feb 2004 12:00:20 +1300 > >I am pleased to announce new nut compatible hardware. Details from: > >http://telogis.com/oem_datasheet.pdf > >It is aimed at telematics applications for OEM's and integrators. > >The hardware has quite a few nice features, and many NutOS enhancements to >support the hardware. It also includes the fabled window simulator. > >It is shipping now in volume. > >Regards >Ralph > >_______________________________________________ >En-Nut-Discussion mailing list >En-Nut-Discussion at egnite.de >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca From HeltonGA at aol.com Tue Feb 17 06:36:58 2004 From: HeltonGA at aol.com (HeltonGA at aol.com) Date: Tue, 17 Feb 2004 00:36:58 EST Subject: [En-Nut-Discussion] Ethereal - RTL8019AS data length mismatch Message-ID: <9f.43c8d24b.2d63027a@aol.com> I am a bit confused about some results that I'm seeing in message lengths captured. Using Ethereal to capture traffic, I try to establish a TCP connection using SuperScan4.0. Ethereal reports a TCP message that is 54 bytes ("54 bytes on wire, 54 bytes captured") in length with SYN bit set, Seq Num xxxx, yada, yada, yada. Anyway - why is the message length 54 bytes ? Isn't the minimum message length supposed to be 60 bytes for Ethernet ? Now on to the RTL8019AS. I captured this same message on my development board. When I read the message length from the message header, it is 64 bytes. Subtract out the 4 bytes for the CRC and there are 60 data bytes. Just what I would have expected. When I read out the 60 bytes from the RTL8019 and buffer them, there are 54 bytes that comprise the Ethernet Header, IP Header, and TCP Header (14 + 20 + 20) plus 6 space characters (0x20). Why is there an apparent mismatch in data lengths ? Is Ethereal just ignoring the extra space characters or is the RTL8019 making them up ? By the way, the IP Total Length field is (40). This would account for the IP Header and TCP Header, but would not account for any "extra" spaces (pads) appended as TCP data. Does anyone know what's going on here ? Thanks in advance. Fiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From deoxy at u.washington.edu Tue Feb 17 07:30:15 2004 From: deoxy at u.washington.edu (Amedee Louis Beaudoin) Date: Mon, 16 Feb 2004 22:30:15 -0800 Subject: [En-Nut-Discussion] CPLD equations In-Reply-To: References: Message-ID: <4031B4F7.4010808@u.washington.edu> Hi Richard, The schematic *is* the guts of the CPLD. There is another file that describes the pin to signal mapping, but it may have changed since I sent the design to Harald. I attached the copy I have. Louis Beaudoin Richard Sloan wrote: > Does anyone have the CPLD equations/design? I see a schematic to > download but its not the guts of the CPLD! > > Thanks! > > >> From: Ralph Mason >> Reply-To: "Ethernut User Chat (English)" >> To: en-Nut-Discussion >> Subject: [En-Nut-Discussion] Announce: Nut Hardware >> Date: Tue, 17 Feb 2004 12:00:20 +1300 >> >> I am pleased to announce new nut compatible hardware. Details from: >> >> http://telogis.com/oem_datasheet.pdf >> >> It is aimed at telematics applications for OEM's and integrators. >> >> The hardware has quite a few nice features, and many NutOS >> enhancements to support the hardware. It also includes the fabled >> window simulator. >> >> It is shipping now in volume. >> >> Regards >> Ralph >> >> _______________________________________________ >> En-Nut-Discussion mailing list >> En-Nut-Discussion at egnite.de >> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: enut202.ucf URL: From damian at commtech.com.au Tue Feb 17 09:48:21 2004 From: damian at commtech.com.au (Damian Slee) Date: Tue, 17 Feb 2004 16:48:21 +0800 Subject: [En-Nut-Discussion] BugFix: Usart reading Xoff doesn't stop Tx Message-ID: Also can we get the examples changed so they use the new Usart device driver instead of Uart ole one. Ie change NutRegisterDevice(&devUart0, 0, 0); to NutRegisterDevice(&devUsartAvr0, 0, 0); Also I haven't been able to get the driver to send an Xon or Xoff yet, so I'm not sure if this is another problem, or something not set. I would have thought a call to this would send an XON imediately? lTmp = USART_MF_XONXOFF; _ioctl(fileno, UART_SETFLOWCONTROL, &lTmp); Usartavr.c Tx Fix static void AvrUsartTxEmpty(void *arg) { register RINGBUF *rbf = (RINGBUF *) arg; register u_char *cp = rbf->rbf_tail; /* * Process pending software flow controls first. */ if (flow_control & (XON_PENDING | XOFF_PENDING)) { if (flow_control & XON_PENDING) { outb(UDRn, ASCII_XOFF); flow_control |= XOFF_SENT; } else { outb(UDRn, ASCII_XON); flow_control &= ~XOFF_SENT; } flow_control &= ~(XON_PENDING | XOFF_PENDING); return; } // Addition ---> if (flow_control & XOFF_RCVD) { /* * If XOFF has been received, we disable the transmit interrupts * and return without sending anything. */ cbi(UCSRnB, UDRIE); return; } // <---- end of Addition From bengt at florin.se Tue Feb 17 09:50:20 2004 From: bengt at florin.se (Bengt Florin) Date: Tue, 17 Feb 2004 09:50:20 +0100 Subject: [En-Nut-Discussion] Ethereal - RTL8019AS data length mismatch In-Reply-To: <9f.43c8d24b.2d63027a@aol.com> Message-ID: <01cd01c3f533$13c65c90$0205a8c0@hugin> 1. Yes, 60 bytes is min and the driver pads with NUL bytes. Does Ethereal really show the length of the ethernet frame or just the length of the received IP packet? 2. The extra spaces are the padding done by the transmitting host to make if >60 bytes. This padding is not shown in the IP header but only in the ethernet frame, of course. So things are probably quite normal. rgds bengan -----Original Message----- From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de]On Behalf Of HeltonGA at aol.com Sent: den 17 februari 2004 06:37 To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] Ethereal - RTL8019AS data length mismatch I am a bit confused about some results that I'm seeing in message lengths captured. Using Ethereal to capture traffic, I try to establish a TCP connection using SuperScan4.0. Ethereal reports a TCP message that is 54 bytes ("54 bytes on wire, 54 bytes captured") in length with SYN bit set, Seq Num xxxx, yada, yada, yada. Anyway - why is the message length 54 bytes ? Isn't the minimum message length supposed to be 60 bytes for Ethernet ? Now on to the RTL8019AS. I captured this same message on my development board. When I read the message length from the message header, it is 64 bytes. Subtract out the 4 bytes for the CRC and there are 60 data bytes. Just what I would have expected. When I read out the 60 bytes from the RTL8019 and buffer them, there are 54 bytes that comprise the Ethernet Header, IP Header, and TCP Header (14 + 20 + 20) plus 6 space characters (0x20). Why is there an apparent mismatch in data lengths ? Is Ethereal just ignoring the extra space characters or is the RTL8019 making them up ? By the way, the IP Total Length field is (40). This would account for the IP Header and TCP Header, but would not account for any "extra" spaces (pads) appended as TCP data. Does anyone know what's going on here ? Thanks in advance. Fiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From damian at commtech.com.au Tue Feb 17 10:45:23 2004 From: damian at commtech.com.au (Damian Slee) Date: Tue, 17 Feb 2004 17:45:23 +0800 Subject: [En-Nut-Discussion] BugFix: Usart half duplex mode doesn't toggle pin Message-ID: Transmit complete interrupt which is required, is only enabled if halfduplex mode is enabled before the uart is initialised. Normally one would open the device, the call SETFLOWCONTROL, in which case transmit complete interrupt never gets enabled. static int AvrUsartSetFlowControl(u_long flags) { ... #ifdef UART_HDX_BIT /* * Set half duplex mode. */ if (flags & USART_MF_HALFDUPLEX) { /* Register transmit complete interrupt. */ if (NutRegisterIrqHandler(&sig_UART_TRANS, AvrUsartTxComplete, &dcb_usart.dcb_rx_rbf)) { return -1; } /* Initially enable the receiver. */ cbi(UART_HDX_PORT, UART_HDX_BIT); sbi(UART_HDX_DDR, UART_HDX_BIT); hdx_control = 1; //-----> /* Enable transmit complete interrupt. */ sbi(UCSRnB, TXCIE); //<----- } else if (hdx_control) { hdx_control = 0; //-----> /* disable transmit complete interrupt */ cbi(UCSRnB, TXCIE); //<----- /* Deregister transmit complete interrupt. */ NutRegisterIrqHandler(&sig_UART_TRANS, 0, 0); cbi(UART_HDX_DDR, UART_HDX_BIT); } #endif ... } From korbai at axelero.hu Tue Feb 17 12:26:41 2004 From: korbai at axelero.hu (Korbai, Zoltan) Date: Tue, 17 Feb 2004 12:26:41 +0100 Subject: [En-Nut-Discussion] PPP (magic number) NUT-3.4.1-RC1 Message-ID: <000901c3f548$eaebfad0$1802a8c0@work> Hi, I tried this version and found that never PPP connection established via GPRS. If I change the line 168 in NET/lcpout.c from if (rejected) { to if (!rejected) { PPP will be ok. (I checked latest CVS and is the same.) Zoltan From bbuenaobra at nip.upd.edu.ph Wed Feb 18 02:51:02 2004 From: bbuenaobra at nip.upd.edu.ph (Berns J. Buenaobra) Date: Tue, 17 Feb 2004 17:51:02 -0800 Subject: [En-Nut-Discussion] GSM/GPRS Module for Ethernut - good candidate brand needed In-Reply-To: <20040217093432.BA7072F42A5@p15095813.pureserver.info> Message-ID: <000101c3f5c1$ad84a330$3a65a8c0@instru.nip.upd.edu.ph> Hello List: Seems to be that the push at my university instrumentation physics lab is to go Web enabled and Wireless. I do not have experience with interfacing a GSM/GPRS modem to the Ethernut (still on the hump of the learning curve!) I would appreciate some wisdom from experiences of the others in the list. Please email me directly for some shared information specially on the "how to" part of the hardware and code. We would like transmit optical scanned data from out optical set-up from the lab to within a kilometer range by GSM, TCP/IP, GPRS or RF Modem. Many thanks for those who would reply and help. Berns Buenaobra Email: bbuenaobra at nip.upd.edu.ph URL: www.nip.upd.edu.ph/ipl From enut at ixo.de Tue Feb 17 18:53:56 2004 From: enut at ixo.de (Waschk,Kolja) Date: Tue, 17 Feb 2004 18:53:56 +0100 (CET) Subject: [En-Nut-Discussion] Problem with Timers In-Reply-To: References: Message-ID: > I'm currently hunting for anything that is causing "almost deterministic" > lockups of my target. In that state it won't even answer ICMP echo reqs. A little status update regarding this problem: 1. I've merged Bengt's "ruggedized" nicrtl driver with our code. That alone however doesn't fix the lock-ups. Just to make sure it's not the driver. 2. I've added NutEnterCritical/ExitCritical at several places in timer.c, event.c and thread.c and a small "paranoia" fix. Now the test loop that caused lockups after max 3 minutes is active since 25 minutes, and still running As soon as I've sorted out if all of the above actually was necessary for stable performance (and only when it really proved to be more stable), I'll post additional details/patches. Kolja -- mr. kolja waschk - haubach-39 - 22765 hh - ger phone +49 40 889130-34 - fax -35 - e-mail s.a. From michael.s at lfiinternational.com Wed Feb 18 03:57:16 2004 From: michael.s at lfiinternational.com (Michael G. Svob) Date: Tue, 17 Feb 2004 18:57:16 -0800 Subject: [En-Nut-Discussion] Ethernut & DMX In-Reply-To: Message-ID: Greetings, Does anyone have experience using an Ethernut to receive and process DMX lighting signals? I'm using a Maxim MAX3084E RS-485 tranceiver chip feeding into USART 0, with baud rate set to 250K, 8 data bits, no parity, and 2 stop bits. Problem is, I can synch on and receive the data (from a known good DMX source), but the received data is a bit funky. For one thing, the MS bit of the data is always "1", so for example data that should be 1 (0x01) is actually returned as 129 (0x81). Also (ignoring the MS bit), for much (but not all) of the range 0-255, other seemingly random bits seem to get set incorrectly for no apparent reason. For example, the value 20 (binary 0001 0100) is received as both 142 (1000 1110) and 156 (1001 1100). For the record, I've tried different baud rates, number of data bits, number of stop bits, etc., but with no success. For what it's worth, I also get exactly the same results with an STK500 and an ATMega16. Thanks in advance for any help that can be extended. Best Regards, Michael Svob From mikec at call-direct.com.au Wed Feb 18 07:32:06 2004 From: mikec at call-direct.com.au (Mike Cornelius) Date: Wed, 18 Feb 2004 17:32:06 +1100 Subject: [En-Nut-Discussion] Bug In NutThreadCreate Message-ID: <054801c3f5e8$f3e19190$2301a8c0@Mike> Hi All, I have found a bug in NutThreadCreate:- NutEnterCritical(); paddr = (const u_short *) fn; // *KU* fn doesn't contain the entry address // of the thread! /* * Allocate stack and thread info structure in one block. */ if ((threadMem = NutHeapAlloc(stackSize + sizeof(NUTTHREADINFO))) == 0) return 0; The above live should read:- if ((threadMem = NutHeapAlloc(stackSize + sizeof(NUTTHREADINFO))) == 0){ NutExitCritical(); return 0; } Or else if you're out of memory you'll end up with a corrupted stack. 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ From francois at asnone.com Wed Feb 18 07:45:24 2004 From: francois at asnone.com (Francois Rademeyer) Date: Wed, 18 Feb 2004 08:45:24 +0200 Subject: [En-Nut-Discussion] Questions re devUart1 Message-ID: <041b01c3f5ea$ca4afbd0$1b00a8c0@sonyfrademeyer> Hi all, When I change from using devDebug1 to devUart1 for stdout it stops working. Has anyone experienced this? I'm sure it could be one of a multitude of problems. I'm also using the devUart0 driver elsewhere in my program with no problems. Something that is also quite peculiar is that I notice that my .bss segment grows almost 700 bytes in size when doing the above mentioned change. I don't know about other people, but when I have NUTDEBUG enabled the standard 4K memory becomes very small indeed. How do I enable external RAM for .bss and .data when working with Nut-Os? Is there any advantage in using the new usart driver above the uart for standard 8N1 operation? How can I set an already active stream to also output to stdout? Thanks, Francois From francois at asnone.com Wed Feb 18 07:57:05 2004 From: francois at asnone.com (Francois Rademeyer) Date: Wed, 18 Feb 2004 08:57:05 +0200 Subject: [En-Nut-Discussion] HTTP problem Message-ID: <043301c3f5ec$6b3fb4d0$1b00a8c0@sonyfrademeyer> Another problem: When I run an HTTP server across a GPRS connection, i.e. not nearly as fast as Ethernet, I experience errors when using html frames, i.e. when the web browser downloads multiple items simultaneously. I have not started to trace this with a packet sniffer and was just hoping that I'm in luck and someone has a solution ready. I use nearly the same code as the httpd example. Thanks again, Francois From towmeup at as.ro Wed Feb 18 08:12:54 2004 From: towmeup at as.ro (Cosmin Buhu) Date: Wed, 18 Feb 2004 09:12:54 +0200 Subject: [En-Nut-Discussion] Http server References: <041b01c3f5ea$ca4afbd0$1b00a8c0@sonyfrademeyer> Message-ID: <000701c3f5ee$a104be10$1e0a030a@devel> Can someone report how is the httpd working in 3.3.2.1 compared with the latest 3.4.1-rc1 from the ethernut download page (it seems I cannot use the cvs with anonymous)? For me in 3.3.2.1 even with retransmission bug fixed I still have locks (missing images in page for example), and in 3.4 is a bigger mess. Strange for me that browsing from a Linux box and a Windows one makes a difference, from Linux is behaving better. Thanks, Cosmin Buhu From damian at commtech.com.au Wed Feb 18 08:19:28 2004 From: damian at commtech.com.au (Damian Slee) Date: Wed, 18 Feb 2004 15:19:28 +0800 Subject: [En-Nut-Discussion] Http server Message-ID: I do get this a little in old and latest version. Have never investigated. I presume it was a limit of running 2 or 4 connection threads in ethernut, when the browser tries to open 4 at a time I think. -----Original Message----- From: Cosmin Buhu [mailto:towmeup at as.ro] Sent: Wednesday, 18 February 2004 3:13 PM To: Ethernut User Chat (English) Subject: [En-Nut-Discussion] Http server Can someone report how is the httpd working in 3.3.2.1 compared with the latest 3.4.1-rc1 from the ethernut download page (it seems I cannot use the cvs with anonymous)? For me in 3.3.2.1 even with retransmission bug fixed I still have locks (missing images in page for example), and in 3.4 is a bigger mess. Strange for me that browsing from a Linux box and a Windows one makes a difference, from Linux is behaving better. Thanks, Cosmin Buhu _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From towmeup at as.ro Wed Feb 18 08:24:00 2004 From: towmeup at as.ro (Cosmin Buhu) Date: Wed, 18 Feb 2004 09:24:00 +0200 Subject: [En-Nut-Discussion] Http server References: Message-ID: <000501c3f5f0$2df5de70$1e0a030a@devel> Limit where ? Opening 6 or more httpd threads in my code makes no visible improvements. Cosmin ----- Original Message ----- From: "Damian Slee" To: "Ethernut User Chat (English)" Sent: Wednesday, February 18, 2004 9:19 AM Subject: RE: [En-Nut-Discussion] Http server I do get this a little in old and latest version. Have never investigated. I presume it was a limit of running 2 or 4 connection threads in ethernut, when the browser tries to open 4 at a time I think. -----Original Message----- From: Cosmin Buhu [mailto:towmeup at as.ro] Sent: Wednesday, 18 February 2004 3:13 PM To: Ethernut User Chat (English) Subject: [En-Nut-Discussion] Http server Can someone report how is the httpd working in 3.3.2.1 compared with the latest 3.4.1-rc1 from the ethernut download page (it seems I cannot use the cvs with anonymous)? For me in 3.3.2.1 even with retransmission bug fixed I still have locks (missing images in page for example), and in 3.4 is a bigger mess. Strange for me that browsing from a Linux box and a Windows one makes a difference, from Linux is behaving better. Thanks, Cosmin Buhu _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From lightfreakde at yahoo.com Wed Feb 18 09:09:17 2004 From: lightfreakde at yahoo.com (Simon Biniek) Date: Wed, 18 Feb 2004 00:09:17 -0800 (PST) Subject: [En-Nut-Discussion] Ethernut & DMX In-Reply-To: Message-ID: <20040218080917.77105.qmail@web13505.mail.yahoo.com> Hi, try to use only one stop bit in the receiver. This may be nessesary due to the fact, that DMX defines no interbyte gap, so the second stop bit on transmitter side is the gap for the receiver. Simon __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools From robert.hildebrand at ims.fhg.de Wed Feb 18 09:13:11 2004 From: robert.hildebrand at ims.fhg.de (Robert Hildebrand) Date: Wed, 18 Feb 2004 09:13:11 +0100 Subject: AW: [En-Nut-Discussion] Http server In-Reply-To: <000501c3f5f0$2df5de70$1e0a030a@devel> Message-ID: When using opera as browser you can limit the number of maximum pallel connections to one server. That is not the real solution (as only valid for opera and I dind't find a similar setting in other browsers) but maybe you can check the behaviour of the Ethernut better. Robert -----Urspr?ngliche Nachricht----- Von: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Cosmin Buhu Gesendet: Mittwoch, 18. Februar 2004 08:24 An: Ethernut User Chat (English) Betreff: Re: [En-Nut-Discussion] Http server Limit where ? Opening 6 or more httpd threads in my code makes no visible improvements. Cosmin ----- Original Message ----- From: "Damian Slee" To: "Ethernut User Chat (English)" Sent: Wednesday, February 18, 2004 9:19 AM Subject: RE: [En-Nut-Discussion] Http server I do get this a little in old and latest version. Have never investigated. I presume it was a limit of running 2 or 4 connection threads in ethernut, when the browser tries to open 4 at a time I think. -----Original Message----- From: Cosmin Buhu [mailto:towmeup at as.ro] Sent: Wednesday, 18 February 2004 3:13 PM To: Ethernut User Chat (English) Subject: [En-Nut-Discussion] Http server Can someone report how is the httpd working in 3.3.2.1 compared with the latest 3.4.1-rc1 from the ethernut download page (it seems I cannot use the cvs with anonymous)? For me in 3.3.2.1 even with retransmission bug fixed I still have locks (missing images in page for example), and in 3.4 is a bigger mess. Strange for me that browsing from a Linux box and a Windows one makes a difference, from Linux is behaving better. Thanks, Cosmin Buhu _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From towmeup at as.ro Wed Feb 18 09:54:26 2004 From: towmeup at as.ro (Cosmin Buhu) Date: Wed, 18 Feb 2004 10:54:26 +0200 Subject: [En-Nut-Discussion] Http server References: Message-ID: <001a01c3f5fc$d0316e50$1e0a030a@devel> With Opera things are improved but even with only one connection at a time/server enabled with a high stress on ethernut (fast clicking...) it still locks. The same happens with my application and stock httpd example as well. Cosmin ----- Original Message ----- From: "Robert Hildebrand" To: "Ethernut User Chat (English)" Sent: Wednesday, February 18, 2004 10:13 AM Subject: AW: [En-Nut-Discussion] Http server When using opera as browser you can limit the number of maximum pallel connections to one server. That is not the real solution (as only valid for opera and I dind't find a similar setting in other browsers) but maybe you can check the behaviour of the Ethernut better. Robert -----Urspr?ngliche Nachricht----- Von: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Cosmin Buhu Gesendet: Mittwoch, 18. Februar 2004 08:24 An: Ethernut User Chat (English) Betreff: Re: [En-Nut-Discussion] Http server Limit where ? Opening 6 or more httpd threads in my code makes no visible improvements. Cosmin ----- Original Message ----- From: "Damian Slee" To: "Ethernut User Chat (English)" Sent: Wednesday, February 18, 2004 9:19 AM Subject: RE: [En-Nut-Discussion] Http server I do get this a little in old and latest version. Have never investigated. I presume it was a limit of running 2 or 4 connection threads in ethernut, when the browser tries to open 4 at a time I think. -----Original Message----- From: Cosmin Buhu [mailto:towmeup at as.ro] Sent: Wednesday, 18 February 2004 3:13 PM To: Ethernut User Chat (English) Subject: [En-Nut-Discussion] Http server Can someone report how is the httpd working in 3.3.2.1 compared with the latest 3.4.1-rc1 from the ethernut download page (it seems I cannot use the cvs with anonymous)? For me in 3.3.2.1 even with retransmission bug fixed I still have locks (missing images in page for example), and in 3.4 is a bigger mess. Strange for me that browsing from a Linux box and a Windows one makes a difference, from Linux is behaving better. Thanks, Cosmin Buhu _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From harald.kipp at egnite.de Wed Feb 18 11:15:29 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 18 Feb 2004 11:15:29 +0100 Subject: [En-Nut-Discussion] HTTP problem In-Reply-To: <043301c3f5ec$6b3fb4d0$1b00a8c0@sonyfrademeyer> Message-ID: <5.1.1.6.0.20040218110019.01c6e4a8@egnite.de> Hi Francois, HTTP adds some difficulties like parallel connections and connects/disconnects at high rates. All applications we tested with GPRS had been single connections, established for a longer period. What I can say is, that troughput is no real problem, PPP seems to work quite reliable at higher data rates. But parallel connections may disclose bugs, which had been undiscovered during our test. The providers we tried recently didn't route our browser requests via Intranet-DLS-Internet-GPRS-Ethernut. So we only tested connecting the other way round, GPRS->DSL. No idea, why this is routed and DSL->GPRS isn't, because from the IP layers view there is no difference. Modern routers are quite intelligent, though. So this test would require to write a specific application, a multiconnect client, which we don't have right know. I'd welcome, if you are able to further investigate the problem. You can trace Ethernut's TCP traffic, but it requires to have the second UART connected. Let me know, if we can help in any way. Regards, Harald From harald.kipp at egnite.de Wed Feb 18 10:58:10 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 18 Feb 2004 10:58:10 +0100 Subject: [En-Nut-Discussion] Http server In-Reply-To: <001a01c3f5fc$d0316e50$1e0a030a@devel> References: Message-ID: <5.1.1.6.0.20040218104031.01befc60@egnite.de> Hi Cosmin, Every TCP server in the world, even the fastest SUN/IBM/HP or whatever will get in trouble sooner or later. SYN attacks are based on this. Because of memory constraints, Ethernut has no pre-assigned buffers for sockets. So your application has to take care of two things: 1. Do not blindly rely on malloc() being succesfull, like many PC programs do. 2. Delay your server thread if memory becomes low. Ethernut is a very small and very slow system, compared with PCs and larger servers. Compared with other 8-Bit systems, it's exceptionally fast and, if you take care of the advices given above, it works very reliable. Sorry for sounding a bit advertising, but I tried some "competitor" products. Just as an example, the Rabbit stack is very complete and works quite well, but is slower, requires more memory and overruns appear much sooner. The Atmel stack is a nice toy, nothing more. The hardware chip (like the one on the newer Atmel Kit) is even more limited regarding concurrent connections. So please keep in mind, that you are running a system, which is similar to the Apple II or Commodore PET. Regards, Harald From francois at asnone.com Wed Feb 18 11:33:35 2004 From: francois at asnone.com (Francois Rademeyer) Date: Wed, 18 Feb 2004 12:33:35 +0200 Subject: [En-Nut-Discussion] HTTP problem References: <5.1.1.6.0.20040218110019.01c6e4a8@egnite.de> Message-ID: <04ea01c3f60a$aa3239b0$1b00a8c0@sonyfrademeyer> Hi Harald, Thanks for the feedback. > The providers we tried recently didn't route our browser > requests via Intranet-DLS-Internet-GPRS-Ethernut. You have to request a public IP from your provider as they all tend to have the GPRS units behind a firewall. They will most probably give you a new APN, username and password and then also charge you for a static IP. With a single html page and one picture I get an error almost every 5th request. My simple CGI pages have not given any problems yet. I do have logging on the 2nd UART and also use ethereal on the browser side. Regards, Francois ----- Original Message ----- From: "Harald Kipp" To: "Ethernut User Chat (English)" Sent: Wednesday, February 18, 2004 12:15 PM Subject: Re: [En-Nut-Discussion] HTTP problem > Hi Francois, > > HTTP adds some difficulties like parallel connections > and connects/disconnects at high rates. All applications we > tested with GPRS had been single connections, established > for a longer period. > > What I can say is, that troughput is no real problem, PPP > seems to work quite reliable at higher data rates. But > parallel connections may disclose bugs, which had been > undiscovered during our test. > > The providers we tried recently didn't route our browser > requests via Intranet-DLS-Internet-GPRS-Ethernut. So we > only tested connecting the other way round, GPRS->DSL. > No idea, why this is routed and DSL->GPRS isn't, because > from the IP layers view there is no difference. Modern > routers are quite intelligent, though. > > So this test would require to write a specific application, > a multiconnect client, which we don't have right know. > > I'd welcome, if you are able to further investigate the > problem. You can trace Ethernut's TCP traffic, but it > requires to have the second UART connected. Let me know, > if we can help in any way. > > Regards, > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From harald.kipp at egnite.de Wed Feb 18 11:29:23 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 18 Feb 2004 11:29:23 +0100 Subject: [En-Nut-Discussion] Questions re devUart1 In-Reply-To: <041b01c3f5ea$ca4afbd0$1b00a8c0@sonyfrademeyer> Message-ID: <5.1.1.6.0.20040218111634.01c3cfc8@egnite.de> Hi Francois, At 08:45 18.02.2004 +0200, you wrote: >Hi all, > >When I change from using devDebug1 to devUart1 for stdout it stops working. >Has anyone experienced this? I'm sure it could be one of a multitude of >problems. I'm also using the devUart0 driver elsewhere in my program with >no problems. Ah, I see, you are already using UART1. >Something that is also quite peculiar is that I notice that my .bss segment >grows almost 700 bytes in size when doing the above mentioned change. I >don't know about other people, but when I have NUTDEBUG enabled the standard >4K memory becomes very small indeed. How do I enable external RAM for .bss >and .data when working with Nut-Os? NUTDEBUG output may not work with devUartx, some outputs rely on polling output. devUart statically pre-allocates it's buffers, so better use devUsart. For RAM usage: Using more than 4k for bss should be no problem (for ICC, enable the external RAM option). But I think there is a problem when using nearly 4k. >Is there any advantage in using the new usart driver above the uart for >standard 8N1 operation? As mentioned above, it allocates its buffers from heap. But its also slower and increases overall interrupt latency. >How can I set an already active stream to also output to stdout? This is no mailing list for C newbies - go playing with BASIC. :-) freopen should do that: http://www.int.gu.edu.au/courses/2010int/tute04.html Regards, Harald From towmeup at as.ro Wed Feb 18 12:24:12 2004 From: towmeup at as.ro (Cosmin Buhu) Date: Wed, 18 Feb 2004 13:24:12 +0200 Subject: [En-Nut-Discussion] Http server References: <5.1.1.6.0.20040218104031.01befc60@egnite.de> Message-ID: <002401c3f611$bc5cef70$1e0a030a@devel> Thanks Harald. However, I do not use any NutHeapAlloc or equivalents in my test code and I kept the piece of code to delay on low memory (and ram usage shows somewhere to 17K free). On latest trials with opera/2 connections ethereal shows complete locks (no response from ethernut, sometimes stopping in the middle of the page, sometimes after acking the query, sometimes not answering at all), no ping etc. With httpd example from app folder it happens too. Am I completely wrong? Are you running the httpd example trouble free ? Cosmin ----- Original Message ----- From: "Harald Kipp" To: "Ethernut User Chat (English)" Sent: Wednesday, February 18, 2004 11:58 AM Subject: Re: [En-Nut-Discussion] Http server > Hi Cosmin, > > Every TCP server in the world, even the fastest SUN/IBM/HP > or whatever will get in trouble sooner or later. SYN attacks > are based on this. > > Because of memory constraints, Ethernut has no pre-assigned > buffers for sockets. So your application has to take care > of two things: > > 1. Do not blindly rely on malloc() being succesfull, like > many PC programs do. > > 2. Delay your server thread if memory becomes low. > > Ethernut is a very small and very slow system, compared > with PCs and larger servers. Compared with other 8-Bit > systems, it's exceptionally fast and, if you take care > of the advices given above, it works very reliable. > > Sorry for sounding a bit advertising, but I tried some > "competitor" products. Just as an example, the Rabbit stack > is very complete and works quite well, but is slower, > requires more memory and overruns appear much sooner. > The Atmel stack is a nice toy, nothing more. The hardware > chip (like the one on the newer Atmel Kit) is even more > limited regarding concurrent connections. > > So please keep in mind, that you are running a system, > which is similar to the Apple II or Commodore PET. > > Regards, > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From harald.kipp at egnite.de Wed Feb 18 12:48:10 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 18 Feb 2004 12:48:10 +0100 Subject: [En-Nut-Discussion] Http server In-Reply-To: <002401c3f611$bc5cef70$1e0a030a@devel> References: <5.1.1.6.0.20040218104031.01befc60@egnite.de> Message-ID: <5.1.1.6.0.20040218123550.031c78f8@egnite.de> Cosmin, Even if you don't use malloc or NutHeapAlloc directly, it may be used indirectly, like fopen (which returns a NULL pointer in that case) etc. The http sample works here as designed. After some successive requests, the connect hangs for some seconds and continues as soon as Ethernut releases the previously allocated sockets. I'm using Mozilla. Anyone else using Opera? I can hardly believe, that this browser causes the problem...but who knows... It may hang for a few seconds. But it should continue and should _always_ respond to pings. As far as I unterstood, you need to reset the board after the problem appears, right? Does it happen with the original httpd sample on all pages? I'm specially interested in the socket list. Can you try this, please? Can you please specify, what board you are using? And what compiler version? I'll try to reproduce it here. Regards, Harald From francois at asnone.com Wed Feb 18 12:51:25 2004 From: francois at asnone.com (Francois Rademeyer) Date: Wed, 18 Feb 2004 13:51:25 +0200 Subject: [En-Nut-Discussion] Questions re devUart1 References: <5.1.1.6.0.20040218111634.01c3cfc8@egnite.de> Message-ID: <051b01c3f615$89b2ac00$1b00a8c0@sonyfrademeyer> Thanks. Not soon after I sent the mail I discovered the problem: devDebug defaults to a baudrate of 115200 and devUart not. > For RAM usage: Using more than 4k for bss should be > no problem (for ICC, enable the external RAM option). > But I think there is a problem when using nearly 4k. How do GCC users achieve this? > This is no mailing list for C newbies - go playing > with BASIC. :-) I'm just a lazy C++ programmer. When you have driven a Porsche for so long it's quite tiresome to find your way around a Trabant. (-: A common nemesis of many folks have once made a very true statement: "Most engineers use a subset of C plus plus called C plus plus minus minus". Cheers, Francois From harald.kipp at egnite.de Wed Feb 18 13:35:55 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 18 Feb 2004 13:35:55 +0100 Subject: [En-Nut-Discussion] Questions re devUart1 In-Reply-To: <051b01c3f615$89b2ac00$1b00a8c0@sonyfrademeyer> References: <5.1.1.6.0.20040218111634.01c3cfc8@egnite.de> Message-ID: <5.1.1.6.0.20040218132432.01c34e78@egnite.de> At 13:51 18.02.2004 +0200, you wrote: >Thanks. > >Not soon after I sent the mail I discovered the problem: devDebug defaults >to a baudrate of 115200 and devUart not. Oops! Exactly the same happened to me two days ago. I tried to test an overclocked Ethernut, running at 18.432 MHz. All baudrate settings failed until I discovered the hardcoded baudrate. For devDebug0 it should be static int DebugIOCtl(NUTDEVICE * dev, int req, void *conf) { if(req == UART_SETSPEED) { outb(UBRR, (u_char) ((((2UL * NutGetCpuClock()) / (*((u_long *)conf) * 16UL)) + 1UL) / 2UL) - 1); return 0; } return -1; } > > For RAM usage: Using more than 4k for bss should be > > no problem (for ICC, enable the external RAM option). > > But I think there is a problem when using nearly 4k. >How do GCC users achieve this? It is fixed in the linker script. If I remember correctly, GCC assumes 64k RAM, so no change should be required. Last time I tried to verify what's going on in case bss ends near below 4k, I ran into the problem of avr-objcopy crashes. Unable to find out, why this happened, I tried to get the source...later find out I need to do the whole toolchain...updated Cygwin... etc...etc...and my day was gone. > > This is no mailing list for C newbies - go playing > > with BASIC. :-) >I'm just a lazy C++ programmer. When you have driven a Porsche for so long >it's quite tiresome to find your way around a Trabant. (-: A common nemesis >of many folks have once made a very true statement: "Most engineers use a >subset of C plus plus called C plus plus minus minus". Too true...or...MSC++, if you look to all the "so called C++" code in the net. uisp is one of the really bad examples (Sorry Ted, I know it's not your code). Harald From towmeup at as.ro Wed Feb 18 13:45:39 2004 From: towmeup at as.ro (Cosmin Buhu) Date: Wed, 18 Feb 2004 14:45:39 +0200 Subject: [En-Nut-Discussion] Http server References: <5.1.1.6.0.20040218104031.01befc60@egnite.de> <5.1.1.6.0.20040218123550.031c78f8@egnite.de> Message-ID: <003401c3f61d$1da9fd30$1e0a030a@devel> Yes it does happen with the socket cgi and other too, static or cgi. And yes, a reset is the only cure. To be sure I made a fresh reinstall of 332. The same. As you said from time to time after a few secs it recovers but also from time to time doesn't, most of them after acking the packet with get. So, board 1.3F, sw 332, avr-gcc from winavr-20030913. 10. network class, 255.0.0.0 mask, also tried with ethernut cabled with one PC only. The things happen with IE, Opera, windows, linux. Cosmin ----- Original Message ----- From: "Harald Kipp" To: "Ethernut User Chat (English)" Sent: Wednesday, February 18, 2004 1:48 PM Subject: Re: [En-Nut-Discussion] Http server > Cosmin, > > Even if you don't use malloc or NutHeapAlloc directly, > it may be used indirectly, like fopen (which returns > a NULL pointer in that case) etc. > > The http sample works here as designed. After some > successive requests, the connect hangs for some seconds > and continues as soon as Ethernut releases the > previously allocated sockets. I'm using Mozilla. > > Anyone else using Opera? I can hardly believe, that > this browser causes the problem...but who knows... > > It may hang for a few seconds. But it should continue > and should _always_ respond to pings. As far as I > unterstood, you need to reset the board after the > problem appears, right? > > Does it happen with the original httpd sample on > all pages? I'm specially interested in the socket > list. Can you try this, please? > > Can you please specify, what board you are using? > And what compiler version? I'll try to reproduce it > here. > > Regards, > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From enut at ixo.de Wed Feb 18 14:16:48 2004 From: enut at ixo.de (Waschk,Kolja) Date: Wed, 18 Feb 2004 14:16:48 +0100 (CET) Subject: [En-Nut-Discussion] Problem with Timers In-Reply-To: References: Message-ID: > 2. I've added NutEnterCritical/ExitCritical at several places in timer.c, > event.c and thread.c and a small "paranoia" fix. Hm, it all turned out to be a "RTFM" problem. No OS fix needed: I failed to disable interrupts in my app before calling NutEvent*Async() routines (The API documentation mentions this requirement, although not boldly enough for me to read it...). Adding Enter/ExitCritical _there_ fixed all problems. Kolja -- mr. kolja waschk - haubach-39 - 22765 hh - ger phone +49 40 889130-34 - fax -35 - e-mail s.a. From harald.kipp at egnite.de Wed Feb 18 20:07:00 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 18 Feb 2004 20:07:00 +0100 Subject: [En-Nut-Discussion] CPLD equations In-Reply-To: Message-ID: <5.1.1.6.0.20040218200138.01bd5290@egnite.de> Oops! My fault. This archive contained the _Eagle_ Schematic I send to Louis to update pin assignments, not the Xilinx schematic file. Thanks to Michael Fischer, who detected this. The archive has been updated. I additionally added the user constraint file. Sorry for the confusion, Harald At 23:54 16.02.2004 -0500, you wrote: >Does anyone have the CPLD equations/design? I see a schematic to download >but its not the guts of the CPLD! > >Thanks! From olischulz at web.de Wed Feb 18 21:20:07 2004 From: olischulz at web.de (Oliver Schulz) Date: Wed, 18 Feb 2004 21:20:07 +0100 Subject: AW: [En-Nut-Discussion] Bug In NutThreadCreate In-Reply-To: <054801c3f5e8$f3e19190$2301a8c0@Mike> Message-ID: <000401c3f65c$9a9cb050$5b42a8c0@ose.de> Yes, sir. You're right. I already commited the bugfixes to CVS in HEAD and nut-3_4-release Cheers, Oliver. > -----Ursprungliche Nachricht----- > Von: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Mike > Cornelius > Gesendet: Mittwoch, 18. Februar 2004 07:32 > An: en-Nut-Discussion at Egnite. De > Betreff: [En-Nut-Discussion] Bug In NutThreadCreate > > > Hi All, > > I have found a bug in NutThreadCreate:- > > NutEnterCritical(); > paddr = (const u_short *) fn; // *KU* fn doesn't > contain the entry > address > // of the thread! > /* > * Allocate stack and thread info structure in one block. > */ > if ((threadMem = NutHeapAlloc(stackSize + > sizeof(NUTTHREADINFO))) == 0) > return 0; > > The above live should read:- > if ((threadMem = NutHeapAlloc(stackSize + > sizeof(NUTTHREADINFO))) == 0){ > NutExitCritical(); > return 0; > } > > Or else if you're out of memory you'll end up with a corrupted stack. > > 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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~~~ > ~~~ > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From olischulz at web.de Wed Feb 18 23:41:38 2004 From: olischulz at web.de (Oliver Schulz) Date: Wed, 18 Feb 2004 23:41:38 +0100 Subject: [En-Nut-Discussion] Http server In-Reply-To: <003401c3f61d$1da9fd30$1e0a030a@devel> Message-ID: <000501c3f670$5f74b540$5b42a8c0@ose.de> Hi Cosmin, Since I cannot yet reproduce this lockup with my system, please do me a favour. Add the following lines in app/httpd/httpserv.c in function THREAD(service,...) just before the call to NutTcpAccept: u_long ul; ul = 3000; NutTcpSetSockOpt (sock, SO_SNDTIMEO, &ul, sizeof(ul)); ...and test again. Cheers, Oliver. > -----Urspr?ngliche Nachricht----- > Von: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Cosmin Buhu > Gesendet: Mittwoch, 18. Februar 2004 13:46 > An: Ethernut User Chat (English) > Betreff: Re: [En-Nut-Discussion] Http server > > > > Yes it does happen with the socket cgi and other too, static > or cgi. And yes, a reset is the only cure. > To be sure I made a fresh reinstall of 332. The same. As you > said from time to time after a few secs it recovers but also from > time to time doesn't, most of them after acking the packet with get. > So, board 1.3F, sw 332, avr-gcc from winavr-20030913. > 10. network class, 255.0.0.0 mask, also tried with > ethernut cabled with > one PC only. > The things happen with IE, Opera, windows, linux. > > Cosmin > > > > ----- Original Message ----- > From: "Harald Kipp" > To: "Ethernut User Chat (English)" > Sent: Wednesday, February 18, 2004 1:48 PM > Subject: Re: [En-Nut-Discussion] Http server > > > > Cosmin, > > > > Even if you don't use malloc or NutHeapAlloc directly, > > it may be used indirectly, like fopen (which returns > > a NULL pointer in that case) etc. > > > > The http sample works here as designed. After some > > successive requests, the connect hangs for some seconds > > and continues as soon as Ethernut releases the > > previously allocated sockets. I'm using Mozilla. > > > > Anyone else using Opera? I can hardly believe, that > > this browser causes the problem...but who knows... > > > > It may hang for a few seconds. But it should continue > > and should _always_ respond to pings. As far as I > > unterstood, you need to reset the board after the > > problem appears, right? > > > > Does it happen with the original httpd sample on > > all pages? I'm specially interested in the socket > > list. Can you try this, please? > > > > Can you please specify, what board you are using? > > And what compiler version? I'll try to reproduce it > > here. > > > > Regards, > > Harald > > > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From towmeup at as.ro Thu Feb 19 06:43:25 2004 From: towmeup at as.ro (Cosmin Buhu) Date: Thu, 19 Feb 2004 07:43:25 +0200 Subject: [En-Nut-Discussion] Http server References: <000501c3f670$5f74b540$5b42a8c0@ose.de> Message-ID: <003101c3f6ab$4b2d3400$1e0a030a@devel> I have both read and write timeouts in my application from start. In the httpd example makes no difference. Most times locks after "[x] Connected 2xxxx", other times with "Creating socket failed", after just reported 24xxx bytes free. Can be a problem with the SRAM ? I'll try today with -DNUTDEBUG but I'm afraid the findings will be null. Thanks, Cosmin ----- Original Message ----- From: "Oliver Schulz" To: "'Ethernut User Chat (English)'" Sent: Thursday, February 19, 2004 12:41 AM Subject: Re: [En-Nut-Discussion] Http server Hi Cosmin, Since I cannot yet reproduce this lockup with my system, please do me a favour. Add the following lines in app/httpd/httpserv.c in function THREAD(service,...) just before the call to NutTcpAccept: u_long ul; ul = 3000; NutTcpSetSockOpt (sock, SO_SNDTIMEO, &ul, sizeof(ul)); ...and test again. Cheers, Oliver. > -----Urspr?ngliche Nachricht----- > Von: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Cosmin Buhu > Gesendet: Mittwoch, 18. Februar 2004 13:46 > An: Ethernut User Chat (English) > Betreff: Re: [En-Nut-Discussion] Http server > > > > Yes it does happen with the socket cgi and other too, static > or cgi. And yes, a reset is the only cure. > To be sure I made a fresh reinstall of 332. The same. As you > said from time to time after a few secs it recovers but also from > time to time doesn't, most of them after acking the packet with get. > So, board 1.3F, sw 332, avr-gcc from winavr-20030913. > 10. network class, 255.0.0.0 mask, also tried with > ethernut cabled with > one PC only. > The things happen with IE, Opera, windows, linux. > > Cosmin > > > > ----- Original Message ----- > From: "Harald Kipp" > To: "Ethernut User Chat (English)" > Sent: Wednesday, February 18, 2004 1:48 PM > Subject: Re: [En-Nut-Discussion] Http server > > > > Cosmin, > > > > Even if you don't use malloc or NutHeapAlloc directly, > > it may be used indirectly, like fopen (which returns > > a NULL pointer in that case) etc. > > > > The http sample works here as designed. After some > > successive requests, the connect hangs for some seconds > > and continues as soon as Ethernut releases the > > previously allocated sockets. I'm using Mozilla. > > > > Anyone else using Opera? I can hardly believe, that > > this browser causes the problem...but who knows... > > > > It may hang for a few seconds. But it should continue > > and should _always_ respond to pings. As far as I > > unterstood, you need to reset the board after the > > problem appears, right? > > > > Does it happen with the original httpd sample on > > all pages? I'm specially interested in the socket > > list. Can you try this, please? > > > > Can you please specify, what board you are using? > > And what compiler version? I'll try to reproduce it > > here. > > > > Regards, > > Harald > > > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From towmeup at as.ro Thu Feb 19 07:39:15 2004 From: towmeup at as.ro (Cosmin Buhu) Date: Thu, 19 Feb 2004 08:39:15 +0200 Subject: [En-Nut-Discussion] Http server References: <000501c3f670$5f74b540$5b42a8c0@ose.de> Message-ID: <001001c3f6b3$18f082a0$1e0a030a@devel> Me again, I found from heap tracing that I have MEMCORR-, MEMNULL and TWICE problems. Right before ethernut locks. Most frequently MEMCORR-. What can cause heap corruption ? Thanks, Cosmin ----- Original Message ----- From: "Oliver Schulz" To: "'Ethernut User Chat (English)'" Sent: Thursday, February 19, 2004 12:41 AM Subject: Re: [En-Nut-Discussion] Http server Hi Cosmin, Since I cannot yet reproduce this lockup with my system, please do me a favour. Add the following lines in app/httpd/httpserv.c in function THREAD(service,...) just before the call to NutTcpAccept: u_long ul; ul = 3000; NutTcpSetSockOpt (sock, SO_SNDTIMEO, &ul, sizeof(ul)); ...and test again. Cheers, Oliver. From damian at commtech.com.au Thu Feb 19 07:50:46 2004 From: damian at commtech.com.au (Damian Slee) Date: Thu, 19 Feb 2004 14:50:46 +0800 Subject: [En-Nut-Discussion] Http server Message-ID: Not big enough stack on all of the threads? -----Original Message----- From: Cosmin Buhu [mailto:towmeup at as.ro] Sent: Thursday, 19 February 2004 2:39 PM To: Ethernut User Chat (English) Subject: Re: [En-Nut-Discussion] Http server Me again, I found from heap tracing that I have MEMCORR-, MEMNULL and TWICE problems. Right before ethernut locks. Most frequently MEMCORR-. What can cause heap corruption ? Thanks, Cosmin ----- Original Message ----- From: "Oliver Schulz" To: "'Ethernut User Chat (English)'" Sent: Thursday, February 19, 2004 12:41 AM Subject: Re: [En-Nut-Discussion] Http server Hi Cosmin, Since I cannot yet reproduce this lockup with my system, please do me a favour. Add the following lines in app/httpd/httpserv.c in function THREAD(service,...) just before the call to NutTcpAccept: u_long ul; ul = 3000; NutTcpSetSockOpt (sock, SO_SNDTIMEO, &ul, sizeof(ul)); ...and test again. Cheers, Oliver. _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From towmeup at as.ro Thu Feb 19 08:03:46 2004 From: towmeup at as.ro (Cosmin Buhu) Date: Thu, 19 Feb 2004 09:03:46 +0200 Subject: [En-Nut-Discussion] Http server References: Message-ID: <001301c3f6b6$84b94140$1e0a030a@devel> Nope. Increasing at a huge 2048/thread, still having MEMCORR-. Cosmin ----- Original Message ----- From: "Damian Slee" To: "Ethernut User Chat (English)" Sent: Thursday, February 19, 2004 8:50 AM Subject: RE: [En-Nut-Discussion] Http server Not big enough stack on all of the threads? -----Original Message----- From: Cosmin Buhu [mailto:towmeup at as.ro] Sent: Thursday, 19 February 2004 2:39 PM To: Ethernut User Chat (English) Subject: Re: [En-Nut-Discussion] Http server Me again, I found from heap tracing that I have MEMCORR-, MEMNULL and TWICE problems. Right before ethernut locks. Most frequently MEMCORR-. What can cause heap corruption ? Thanks, Cosmin ----- Original Message ----- From: "Oliver Schulz" To: "'Ethernut User Chat (English)'" Sent: Thursday, February 19, 2004 12:41 AM Subject: Re: [En-Nut-Discussion] Http server Hi Cosmin, Since I cannot yet reproduce this lockup with my system, please do me a favour. Add the following lines in app/httpd/httpserv.c in function THREAD(service,...) just before the call to NutTcpAccept: u_long ul; ul = 3000; NutTcpSetSockOpt (sock, SO_SNDTIMEO, &ul, sizeof(ul)); ...and test again. Cheers, Oliver. _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From Brett.Abbott at digital-telemetry.com Thu Feb 19 20:23:49 2004 From: Brett.Abbott at digital-telemetry.com (Brett Abbott) Date: Fri, 20 Feb 2004 08:23:49 +1300 Subject: [En-Nut-Discussion] Http server Message-ID: <40350D45.8060903@digital-telemetry.com> Cosmin A couple of ideas... 1. Have you tried a second ethernut (just in case). 2. If you have a JTAG unit, trace the location of the heap that is being corrupted - this assumes it reproduces in the same place each time (but can often be engineered this way), place a breakpoint on the data memory at the expected location. Obviously you will see the owner updating the memory, but this will also give you a means to identify what else is changing the memory. This requires you to know what a good heap looks like so you can spot the difference. AVR Studio helps by changing the colour of recently changed memory values. 3. As a third thought, to be ignored if you are using the sample code EXACTLY unchanged, is that it is very easy to reuse the pointer to the device, perhaps initialising or opening it twice, or writing (fprintf) to a pointer/device that hasnt been opened - this generally has fatal consequence matching the symptoms you see. Hope this helps Brett -- ----------------------------------------------------------------- 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 Brett.Abbott at digital-telemetry.com Fri Feb 20 02:22:08 2004 From: Brett.Abbott at digital-telemetry.com (Brett Abbott) Date: Fri, 20 Feb 2004 14:22:08 +1300 Subject: [En-Nut-Discussion] eboot, a tricky bit. Message-ID: <40356140.4000100@digital-telemetry.com> Hi Ive almost completed the port to ICC of eboot but have found a segment of code that has stumped my self taught C programming skills. Could I ask if someone could advise us of the appropriate ICC equivalent? In particular, the line Im having trouble compiling is "sum += *((u_short *) data)++;" Many Thanks, Any help appreciated. Brett from eboot\ip.c: /*! * \brief Calculate the IP checksum over a block of data. * * \param data Pointer to the data block. * \param size Size of the data block. * * \return The checksum in network byte order. */ static u_short IpChkSum(const void *data, u_short size) { register u_long sum = 0; for (;;) { if (size < 2) break; sum += *((u_short *) data)++; size -= 2; } if (size) sum += *(u_char *) data; while ((size = (u_short) (sum >> 16)) != 0) sum = (u_short) sum + size; return (u_short) sum ^ 0xFFFF; } -- ----------------------------------------------------------------- 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 damian at commtech.com.au Fri Feb 20 02:35:24 2004 From: damian at commtech.com.au (Damian Slee) Date: Fri, 20 Feb 2004 09:35:24 +0800 Subject: [En-Nut-Discussion] eboot, a tricky bit. Message-ID: I'm pretty sure its incrementing the contents of memory, not the ptr. the above/below code would help to double check. u_short *tmp; tmp = (u_short *) data; *tmp++; // or (*tmp)++ if it reads better _____ From: Brett Abbott [mailto:Brett.Abbott at digital-telemetry.com] Sent: Friday, 20 February 2004 9:22 AM To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] eboot, a tricky bit. Hi Ive almost completed the port to ICC of eboot but have found a segment of code that has stumped my self taught C programming skills. Could I ask if someone could advise us of the appropriate ICC equivalent? In particular, the line Im having trouble compiling is "sum += *((u_short *) data)++;" Many Thanks, Any help appreciated. Brett from eboot\ip.c: /*! * \brief Calculate the IP checksum over a block of data. * * \param data Pointer to the data block. * \param size Size of the data block. * * \return The checksum in network byte order. */ static u_short IpChkSum(const void *data, u_short size) { register u_long sum = 0; for (;;) { if (size < 2) break; sum += *((u_short *) data)++; size -= 2; } if (size) sum += *(u_char *) data; while ((size = (u_short) (sum >> 16)) != 0) sum = (u_short) sum + size; return (u_short) sum ^ 0xFFFF; } -- ----------------------------------------------------------------- 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 damian at commtech.com.au Fri Feb 20 02:38:06 2004 From: damian at commtech.com.au (Damian Slee) Date: Fri, 20 Feb 2004 09:38:06 +0800 Subject: [En-Nut-Discussion] eboot, a tricky bit. Message-ID: I should have read on; it looks like the ptr is being incremented u_short *tmp; tmp = (u_short *) data; sum += *tmp; data += sizeof(u_short); _____ From: Damian Slee Sent: Friday, 20 February 2004 9:35 AM To: Brett.Abbott at digital-telemetry.com; Ethernut User Chat (English) Subject: RE: [En-Nut-Discussion] eboot, a tricky bit. I'm pretty sure its incrementing the contents of memory, not the ptr. the above/below code would help to double check. u_short *tmp; tmp = (u_short *) data; *tmp++; // or (*tmp)++ if it reads better _____ From: Brett Abbott [mailto:Brett.Abbott at digital-telemetry.com] Sent: Friday, 20 February 2004 9:22 AM To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] eboot, a tricky bit. Hi Ive almost completed the port to ICC of eboot but have found a segment of code that has stumped my self taught C programming skills. Could I ask if someone could advise us of the appropriate ICC equivalent? In particular, the line Im having trouble compiling is "sum += *((u_short *) data)++;" Many Thanks, Any help appreciated. Brett from eboot\ip.c: /*! * \brief Calculate the IP checksum over a block of data. * * \param data Pointer to the data block. * \param size Size of the data block. * * \return The checksum in network byte order. */ static u_short IpChkSum(const void *data, u_short size) { register u_long sum = 0; for (;;) { if (size < 2) break; sum += *((u_short *) data)++; size -= 2; } if (size) sum += *(u_char *) data; while ((size = (u_short) (sum >> 16)) != 0) sum = (u_short) sum + size; return (u_short) sum ^ 0xFFFF; } -- ----------------------------------------------------------------- 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 towmeup at as.ro Fri Feb 20 07:03:51 2004 From: towmeup at as.ro (Cosmin Buhu) Date: Fri, 20 Feb 2004 08:03:51 +0200 Subject: [En-Nut-Discussion] Http server References: <40350D45.8060903@digital-telemetry.com> Message-ID: <000501c3f777$50bcb860$1e0a030a@devel> Thanks Brett, For one, hope to test soon. For three, yes the unchanged httpd, on heavy stress (just refresh page in browser quick enough). For two, I haven't a JTAG unit, but hope to buy an Olimex one soon. I tested other apps too, some strange things appeared too (like sockets blocked on send even if there are timeouts set, not returning from unsuccessful dns queries). Hmm, maybe because I'm a self trained programmer. Regards, Cosmin ----- Original Message ----- From: "Brett Abbott" To: Sent: Thursday, February 19, 2004 9:23 PM Subject: RE: [En-Nut-Discussion] Http server > Cosmin > > A couple of ideas... > > 1. Have you tried a second ethernut (just in case). > 2. If you have a JTAG unit, trace the location of the heap that is being > corrupted - this assumes it reproduces in the same place each time (but > can often be engineered this way), place a breakpoint on the data memory > at the expected location. Obviously you will see the owner updating the > memory, but this will also give you a means to identify what else is > changing the memory. This requires you to know what a good heap looks > like so you can spot the difference. AVR Studio helps by changing the > colour of recently changed memory values. > 3. As a third thought, to be ignored if you are using the sample code > EXACTLY unchanged, is that it is very easy to reuse the pointer to the > device, perhaps initialising or opening it twice, or writing (fprintf) > to a pointer/device that hasnt been opened - this generally has fatal > consequence matching the symptoms you see. > > Hope this helps > Brett > > -- > ----------------------------------------------------------------- > 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.cgi/en-nut-discussion > From HeltonGA at aol.com Fri Feb 20 19:59:26 2004 From: HeltonGA at aol.com (HeltonGA at aol.com) Date: Fri, 20 Feb 2004 13:59:26 EST Subject: [En-Nut-Discussion] TCP connection sequence question Message-ID: <11e.2af65d45.2d67b30e@aol.com> I am having a problem making a TCP connection with my development board and code. This is not an Ethernut problem. Here is the problem. When the client (SuperScan in this case) requests to open a TCP connection, it sends the following information (captured using Ethereal) INFO Field 1089 > http [SYN] Seq=609287992 Ack=0 Win=64240 Len=0 My code's response was: http > 1089 [SYN, ACK] Seq=3094077 Ack=609287993 Win=64240 Len=0 This is what I would have expected from the client to complete the connecton: 1089 > http [ACK] Seq=609287993 Ack=3094078 Win=64240 Len=0 The client should have ACKed my (server's) last Seq number + 1 and repeated the server's last Ack value in it's Seq value. This is based on my understanding of RFC793, pg 31. However, I got this response to my ACK: 1089 > http [SYN] Seq=609287992 Ack=0 Win=64240 Len=0 Is there a problem with SuperScan or is my understanding of the TCP connection sequence incorrect ? Thanks, Fiz -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: tcpget2.txt URL: From harald.kipp at egnite.de Fri Feb 20 20:32:01 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Fri, 20 Feb 2004 20:32:01 +0100 Subject: [En-Nut-Discussion] TCP connection sequence question In-Reply-To: <11e.2af65d45.2d67b30e@aol.com> Message-ID: <5.1.1.6.0.20040220202951.01c6bbd8@egnite.de> > >However, I got this response to my ACK: >1089 > http [SYN] Seq=609287992 Ack=0 Win=64240 Len=0 It simply didn't receive the SYN/ACK and thus repeats the previous SYN. Harald From Brett.Abbott at digital-telemetry.com Sun Feb 22 04:15:03 2004 From: Brett.Abbott at digital-telemetry.com (Brett Abbott) Date: Sun, 22 Feb 2004 16:15:03 +1300 Subject: [En-Nut-Discussion] Where in the CVS is eboot? Message-ID: <40381EB7.3000507@digital-telemetry.com> Hi Ive been looking in the CVS repository for eboot (Ethernut 1 boot loader) but cannot find the latest source. (or any for that matter - just appload which appears to be for Ethernut 2 only). Could someone email me a zip of the latest versions or point me to a copy. Im porting the 3.3.0 version to ICC but want to ensure I have the latest version. This would be much appreciated. Thanks Brett -- ----------------------------------------------------------------- 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 ching at cmeng.com.hk Fri Feb 20 03:05:18 2004 From: ching at cmeng.com.hk (Ching Chi Fai) Date: Fri, 20 Feb 2004 10:05:18 +0800 Subject: [En-Nut-Discussion] The EEPROM was lost? Message-ID: <000801c3f755$fea03960$b401a8c0@cmeng.local> When i download the new HEX to the ethernut board, then all EEPROM was Clear. But our board can not be init. the ethernet port. any body have a sample of the EEPROM, and give help for me? Thanks Ching Chi Fai. -------------- next part -------------- An HTML attachment was scrubbed... URL: From seek25 at yahoo.com Sun Feb 22 13:52:00 2004 From: seek25 at yahoo.com (Whatever Org) Date: Sun, 22 Feb 2004 04:52:00 -0800 (PST) Subject: [En-Nut-Discussion] rtl8019 driver troubles In-Reply-To: <40381EB7.3000507@digital-telemetry.com> Message-ID: <20040222125200.12984.qmail@web11203.mail.yahoo.com> Hello, I know that Ehernut doesn't use an ISA card, but the init and receive/send must be same. The problem I encounter is that sometimes I read wrong MAC (FF:FF:etc or somehow I left first byte, so 2nd becomes 1st, and so on, last one always beign 0x20, after few resets of NIC and STK500 problem dissapear) and also sometimes packets looks like didn't hit the NIC, I mean the led blinks, no ARP is send and my debug code seems that nothing is received. Also this situation is fixed after few resets. So there must be a bad timing or wrong init sequence? Sometimes, I receive ethernet frame almost fine, except that arp 0x06 type becomes 0x16, and the same for all of them. All things works if I reset few times... It may help if somebody knows ISA IOR/IOW strobes timing, the HARD RESET delay, and also the correct rl8019 init sequence, with delays, if exists, between each pack read/write. All of my code is in ASM, but I have no problem porting from C to ASM :) Digitaly yours, Cornel I. __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools From HeltonGA at aol.com Sun Feb 22 19:14:16 2004 From: HeltonGA at aol.com (HeltonGA at aol.com) Date: Sun, 22 Feb 2004 13:14:16 EST Subject: [En-Nut-Discussion] rtl8019 driver troubles Message-ID: <115.2f145a3f.2d6a4b78@aol.com> I've had similar problems when I was developing my RTL8019AS driver. One important piece of information that was not immediately obvious from the datasheet is the active state of the IOWB and IORB. Looking at the pinout and pin descriptions, you might assume that the active state of these pins are active high. WRONG ! They are in fact active low signals. Look at the timing diagram on page 47 of the datasheet. A few strategically placed "NOP"s can help on timing issues as well. Pay particular attention to T4,T6,T7,T8 timing. When my code was using active high signals for IOWB and IORB, I would get results similar to yours. It sort of worked, but data was sometimes skewed and data was not as expected. This may not solve your problem, but it can't hurt to refer to the datasheet to make sure your driver complys with timing requirements for the 8019. Here is a link to download the latest datasheet. http://www.realtek.com.tw/downloads/downloads1-3.aspx?spec=True& compamodel=RTL8019AS Good Luck, Fiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbuenaobra at nip.upd.edu.ph Tue Feb 24 00:13:19 2004 From: bbuenaobra at nip.upd.edu.ph (Berns J. Buenaobra) Date: Mon, 23 Feb 2004 15:13:19 -0800 Subject: [En-Nut-Discussion] How to GPRS using the Ethernet 1.3F board References: <20040221110002.B4D452F42A5@p15095813.pureserver.info> Message-ID: <015d01c3fa62$a08585f0$6565a8c0@instru.nip.upd.edu.ph> Hello: There is a connection merit that outways SMS messaging using GPRS I was told. My question is how do you begin GPRS interfacing the Ethernut? What steps has to be done? Codes to look at? Thanks, Berns B. From simon.clarke217 at ntlworld.com Mon Feb 23 09:51:56 2004 From: simon.clarke217 at ntlworld.com (Simon Clarke) Date: Mon, 23 Feb 2004 08:51:56 -0000 Subject: [En-Nut-Discussion] How to GPRS using the Ethernet 1.3F board References: <20040221110002.B4D452F42A5@p15095813.pureserver.info> <015d01c3fa62$a08585f0$6565a8c0@instru.nip.upd.edu.ph> Message-ID: <00e401c3f9ea$4f7691e0$b57ba8c0@davids2000> ok first off compile ethernut with nutdebug set , i think you said you had an ethernut pcb version 1.3 add -DNUTDEBUG to hwdef entry in userconf.mk and get the pppc.c example working ( appicc directory these are for icc ) connecting to a ppp server i.e a windows 2000 or XP serial port set up for incomming connections using ppp ( easy enough to do ) you may also need to have handshake lines CTS & RTS working too ( modem.h ) ( this is where i am stuck at the moment , i get to the point of ppp configure and it just sits there ! ) so think i need handshake lines then here's the start application done for GPRS you need to decide which gprs phone or module you wish to use , i have a nokia 6310i and a dlr-3p cable to connect to a serial port ( not usb version ) or use a GPRS Module such as a Siemens MC45 , Sony erricson GM47 both are known to work fine with ethernut . which ever gprs provider you use ( let me know which one ) you need to ring them and get GPRS internet connection enabled ( not done by default ) also ask them for a permanant IP Address ( their may be a charge additional to normal ) as most GPRS phones are held behind a firewall .( you could leave this till later not sure if we need it yet ) ----- Original Message ----- From: "Berns J. Buenaobra" To: Sent: Monday, February 23, 2004 11:13 PM Subject: [En-Nut-Discussion] How to GPRS using the Ethernet 1.3F board > Hello: > > There is a connection merit that outways SMS messaging using GPRS I was > told. My question is how do you begin GPRS interfacing the Ethernut? What > steps has to be done? Codes to look at? > > Thanks, > > Berns B. > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: GPRS-PPP.C URL: From bbuenaobra at nip.upd.edu.ph Tue Feb 24 04:08:47 2004 From: bbuenaobra at nip.upd.edu.ph (Berns J. Buenaobra) Date: Mon, 23 Feb 2004 19:08:47 -0800 Subject: [En-Nut-Discussion] Re: En-Nut-Discussion Digest, Vol 4, Issue 29 References: <20040223110004.A570C2F42A3@p15095813.pureserver.info> Message-ID: <000e01c3fa83$84e202d0$6565a8c0@instru.nip.upd.edu.ph> Great thanks! Looks like a fine code. Berns B. From damian at commtech.com.au Tue Feb 24 04:41:07 2004 From: damian at commtech.com.au (Damian Slee) Date: Tue, 24 Feb 2004 11:41:07 +0800 Subject: [En-Nut-Discussion] fix for - Realm: cgi"Content-Type: text/html Message-ID: httpd.c needed a \r\n at the end of auth_fmt_P[]. Otherwise "Content-Type: text/html" gets appended to the line, not on a new line. void NutHttpSendError(FILE * stream, REQUEST * req, int status) { .. static prog_char auth_fmt_P[] = "WWW-Authenticate: Basic realm=\"%s\"\r\n"; Now displays "cgi-bin" as the realm, not "cgi"Content-Type: text/html" in internet explorer. From damian at commtech.com.au Tue Feb 24 09:05:36 2004 From: damian at commtech.com.au (Damian Slee) Date: Tue, 24 Feb 2004 16:05:36 +0800 Subject: [En-Nut-Discussion] Http server - ethereal Message-ID: I have been looking at this in more detail today, cause I have had the same problem as Cosmin since I started using ethernut 6+months ago. Running latest CVS, and new realtek driver. I had this problem before the new realtek driver. I have a frames page with 3 sections in it, so 3 html files + frame setup html file. Only text content + forms on the pages. The problem is that the main frame with a form on it sits there trying to load for about 20 seconds, then it loads. I have traced this with Ethereal. If I click on one of my menu links in the left frame, forcing browser to open new connection, the form loads imediately. Originally I though this was cause I was only running 2 http threads, but changing this to 4 or 8 makes no difference. Like Cosmin indicated last week. Even stranger, after not being able to solve it, I enabled NUTDEBUG on tcp. Got some nice debug out the serial port. I can no longer replicate the problem. Remove NUTDEBUG, and problem comes back. I don't think it is low memory causing this, it would be worse with NUTDEBUG wouldn't it? I captured with etherreal, powered on ethernut, then opened browser and replicated the problem. Stop capture 20+ seconds later, once it had fully loaded with no intervention. Capture showed; (anyone know how to export to txt file in ethereal?) (PC port number in brackets) (I have left off the trailing ACK, FIN ACK) (2104) TCP syn sent by PC to ethernut for first HTTP request ARP lookup by ethernut (2104) SYN ACK sent back to PC, and ACK back again (2104) Data (2104) FIN ACK (2106) TCP syn sent by PC (2106) SYN ACK sent back to PC, , and ACK back again (2106) data (2108) TCP syn sent by PC (2109) TCP syn sent by PC (this appears to get lost) (2106) FIN ACK (2108) SYN ACK sent back to PC, , and ACK back again (2108) data (3 seconds later) (2109) TCP syn sent by PC (this appears to get lost, again) (6 seconds later) (2109) TCP syn sent by PC (this appears to get lost, again) (12 seconds later, error must be reported back to browser after 3 Syn timeouts) (browser gives up on port 2109, closes socket and tries open another socket) (2110) TCP syn sent by PC ~1 millisecond later (2110) SYN ACK sent back to PC, , and ACK back again (2110) data < page loaded completely > Repeatable every time from power on. Sometimes while refreshing. ----------------------------------------------------------- These are the scenarios as I see it? 1.) If the first (2109) Syn got lost Why don't the 2nd or 3rd Syn, get Syn,Acked? 2.) Low memory. Then 9 seconds later the other threads have well and truly stopped, and memory been freed, why shouldn't it be able to handle the Syn's being sent then? 3.) Syn Ack from ethernut got lost, and no further Syn Acks are sent? I not sure, should another Syn Ack be sent in reponse to a received Syn, 3 and 9 seconds later? 4.) Its like that port number gets barred. Any ideas on how to move forward on this? From francois at asnone.com Tue Feb 24 14:15:36 2004 From: francois at asnone.com (Francois Rademeyer) Date: Tue, 24 Feb 2004 15:15:36 +0200 Subject: [En-Nut-Discussion] Thread stack Message-ID: <06e901c3fad8$4b341410$1b00a8c0@sonyfrademeyer> Hi everyone, I have some stupid questions: Lately I have become very confused with all the GCC, AVR & NUT memories. I am trying to find a good balance for the stack size specified when creating threads. Except for all the registers that get pushed onto it when a thread swap occurs, what else uses the thread stack? Unlike larger processors, where local variables goes onto the stack, with the AVR they go into .bss and .data, right? Thanks, Francois From dferbas at dfsoft.cz Tue Feb 24 15:42:03 2004 From: dferbas at dfsoft.cz (Dusan Ferbas) Date: Tue, 24 Feb 2004 15:42:03 +0100 Subject: [En-Nut-Discussion] Http server - ethereal In-Reply-To: <20040224110004.1B2352F42A6@p15095813.pureserver.info> References: <20040224110004.1B2352F42A6@p15095813.pureserver.info> Message-ID: <6.0.1.1.2.20040224151421.01c92f80@pop3.servery.cz> Hi, I experienced something similar 4 months ago. I reported it as a lost FIN packets. I suggest to collect our observations with Nut's TCP. I am interested if this appears to happen also with SMC chip on Ethernut 2 boards ? And what are memory and sockets configuration of your applications - how many threads, amount of available heap, how many http threads, which options are set, how many files needed for your web page, etc. Detailed comment follows: ---- If you do not know stream length at the beginning then Content-Length is missing in http header. Web browser waits for connection close to assume file was fully sent. If FIN is lost then it waits (IE and Mozilla 1.5 tested) forever. This never happens if there is a need only for 1 concurrent http connection. We have 1 html and 2 small picture files (667 and 884 bytes). Sometimes it happens that both pictures are not loaded. Then we have a .swf file (30kB) and 2 .xml files. With .swf we are sending Content-Length and never experienced unsent file (hopefully Flash will not start otherwise). Sometimes it happens that .xml (without Content-Length) are not loaded. Reloading by Ctrl-R (Mozilla) or Reload button always helps. We know Nut is not restarted even due to watch dog reset. This behaviour got better after Oliver Schulz contributed his timing changes in TCP. Hope this helps a little and directs to some debugging effort. I think that this can happen according either to problems with packet transfer from RTL chip or because of some misusage or crossusage of event resources. > u_long ul; > ul = 3000; > NutTcpSetSockOpt (sock, SO_SNDTIMEO, &ul, sizeof(ul)); > > if (NutTcpSetSockOpt(sock, TCP_MAXSEG, &tcp_mss, sizeof(tcp_mss))) > LOG_MSG("%u. Cannot set MSS sock opt\n", id); > > if (NutTcpSetSockOpt(sock, SO_SNDBUF, &tcp_mss, sizeof(tcp_mss))) > LOG_MSG("%u. Cannot set output buffer sock opt\n", id); > > NutTcpAccept(sock, gBoardDatap->http_port); // Listen on http > port (default:80). If we return, we got a client. >Date: Tue, 24 Feb 2004 16:05:36 +0800 >From: "Damian Slee" >Subject: RE: [En-Nut-Discussion] Http server - ethereal >To: "Ethernut User Chat (English)" > > >I have been looking at this in more detail today, cause I have had the >same problem as Cosmin since I started using ethernut 6+months ago. > >Running latest CVS, and new realtek driver. I had this problem before >the new realtek driver. > >I have a frames page with 3 sections in it, so 3 html files + frame >setup html file. Only text content + forms on the pages. > >The problem is that the main frame with a form on it sits there trying >to load for about 20 seconds, then it loads. I have traced this with >Ethereal. If I click on one of my menu links in the left frame, forcing >browser to open new connection, the form loads imediately. > >Originally I though this was cause I was only running 2 http threads, >but changing this to 4 or 8 makes no difference. Like Cosmin indicated >last week. > >... > >Any ideas on how to move forward on this? Dusan Ferbas www.dfsoft.cz From francois at asnone.com Tue Feb 24 16:59:47 2004 From: francois at asnone.com (Francois Rademeyer) Date: Tue, 24 Feb 2004 17:59:47 +0200 Subject: [En-Nut-Discussion] Thread stack References: <06e901c3fad8$4b341410$1b00a8c0@sonyfrademeyer> Message-ID: <06fd01c3faef$3a92e8e0$1b00a8c0@sonyfrademeyer> Ignore the message, I have figured it out by now. ----- Original Message ----- From: "Francois Rademeyer" To: "Ethernut User Chat (English)" Sent: Tuesday, February 24, 2004 3:15 PM Subject: [En-Nut-Discussion] Thread stack > Hi everyone, > > I have some stupid questions: > > Lately I have become very confused with all the GCC, AVR & NUT memories. I > am trying to find a good balance for the stack size specified when creating > threads. Except for all the registers that get pushed onto it when a thread > swap occurs, what else uses the thread stack? Unlike larger processors, > where local variables goes onto the stack, with the AVR they go into .bss > and .data, right? > > Thanks, > Francois > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From Gila at home.nl Tue Feb 24 21:37:27 2004 From: Gila at home.nl (Gila) Date: Tue, 24 Feb 2004 20:37:27 +0000 Subject: [En-Nut-Discussion] Thread stack In-Reply-To: <06fd01c3faef$3a92e8e0$1b00a8c0@sonyfrademeyer> References: <06e901c3fad8$4b341410$1b00a8c0@sonyfrademeyer> <06fd01c3faef$3a92e8e0$1b00a8c0@sonyfrademeyer> Message-ID: <1077655047.3501.0.camel@Gila> On Tue, 2004-02-24 at 15:59, Francois Rademeyer wrote: > Ignore the message, I have figured it out by now. Mind sharing it ? :) > ----- Original Message ----- > From: "Francois Rademeyer" > To: "Ethernut User Chat (English)" > Sent: Tuesday, February 24, 2004 3:15 PM > Subject: [En-Nut-Discussion] Thread stack > > > > Hi everyone, > > > > I have some stupid questions: > > > > Lately I have become very confused with all the GCC, AVR & NUT memories. > I > > am trying to find a good balance for the stack size specified when > creating > > threads. Except for all the registers that get pushed onto it when a > thread > > swap occurs, what else uses the thread stack? Unlike larger processors, > > where local variables goes onto the stack, with the AVR they go into .bss > > and .data, right? > > > > Thanks, > > Francois > > > > > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From damian at commtech.com.au Wed Feb 25 03:04:59 2004 From: damian at commtech.com.au (Damian Slee) Date: Wed, 25 Feb 2004 10:04:59 +0800 Subject: [En-Nut-Discussion] Http server - ethereal Message-ID: Originally 3 threads(1socket, 1uart, 1watchdog) + idle thread + 2 http threads Tried yesterday 3 threads + idle thread + 8 http threads Tried yesterday NUTDEBUG 2 threads + idle thread + 8 http threads. Problem disappeared. Tried yesterday 2 threads + idle thread + 8 http threads. Problem re-appears Content-Length sent with the 4 html files loaded. 1 index + 3 frame html files. They are all crurom generated. Always the last one gets stuck. Tried the old NIC driver again this morning, still the same. Ethernut does seem to go very quiet for that Syn retry 6 second period, like its either not receiving anything, or trying to respond, and its not being sent. Which of these, I'll try find out today. -----Original Message----- From: Dusan Ferbas [mailto:dferbas at dfsoft.cz] Sent: Tuesday, 24 February 2004 10:42 PM To: en-nut-discussion at egnite.de Subject: Re: RE: [En-Nut-Discussion] Http server - ethereal Hi, I experienced something similar 4 months ago. I reported it as a lost FIN packets. I suggest to collect our observations with Nut's TCP. I am interested if this appears to happen also with SMC chip on Ethernut 2 boards ? And what are memory and sockets configuration of your applications - how many threads, amount of available heap, how many http threads, which options are set, how many files needed for your web page, etc. Detailed comment follows: ---- If you do not know stream length at the beginning then Content-Length is missing in http header. Web browser waits for connection close to assume file was fully sent. If FIN is lost then it waits (IE and Mozilla 1.5 tested) forever. This never happens if there is a need only for 1 concurrent http connection. We have 1 html and 2 small picture files (667 and 884 bytes). Sometimes it happens that both pictures are not loaded. Then we have a .swf file (30kB) and 2 .xml files. With .swf we are sending Content-Length and never experienced unsent file (hopefully Flash will not start otherwise). Sometimes it happens that .xml (without Content-Length) are not loaded. Reloading by Ctrl-R (Mozilla) or Reload button always helps. We know Nut is not restarted even due to watch dog reset. This behaviour got better after Oliver Schulz contributed his timing changes in TCP. Hope this helps a little and directs to some debugging effort. I think that this can happen according either to problems with packet transfer from RTL chip or because of some misusage or crossusage of event resources. > u_long ul; > ul = 3000; > NutTcpSetSockOpt (sock, SO_SNDTIMEO, &ul, sizeof(ul)); > > if (NutTcpSetSockOpt(sock, TCP_MAXSEG, &tcp_mss, sizeof(tcp_mss))) > LOG_MSG("%u. Cannot set MSS sock opt\n", id); > > if (NutTcpSetSockOpt(sock, SO_SNDBUF, &tcp_mss, sizeof(tcp_mss))) > LOG_MSG("%u. Cannot set output buffer sock opt\n", > id); > > NutTcpAccept(sock, gBoardDatap->http_port); // Listen on http > port (default:80). If we return, we got a client. >Date: Tue, 24 Feb 2004 16:05:36 +0800 >From: "Damian Slee" >Subject: RE: [En-Nut-Discussion] Http server - ethereal >To: "Ethernut User Chat (English)" > > >I have been looking at this in more detail today, cause I have had the >same problem as Cosmin since I started using ethernut 6+months ago. > >Running latest CVS, and new realtek driver. I had this problem before >the new realtek driver. > >I have a frames page with 3 sections in it, so 3 html files + frame >setup html file. Only text content + forms on the pages. > >The problem is that the main frame with a form on it sits there trying >to load for about 20 seconds, then it loads. I have traced this with >Ethereal. If I click on one of my menu links in the left frame, >forcing browser to open new connection, the form loads imediately. > >Originally I though this was cause I was only running 2 http threads, >but changing this to 4 or 8 makes no difference. Like Cosmin indicated >last week. > >... > >Any ideas on how to move forward on this? Dusan Ferbas www.dfsoft.cz _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From francois at asnone.com Wed Feb 25 07:26:01 2004 From: francois at asnone.com (Francois Rademeyer) Date: Wed, 25 Feb 2004 08:26:01 +0200 Subject: [En-Nut-Discussion] Thread stack References: <06e901c3fad8$4b341410$1b00a8c0@sonyfrademeyer><06fd01c3faef$3a92e8e0$1b00a8c0@sonyfrademeyer> <1077655047.3501.0.camel@Gila> Message-ID: <071d01c3fb68$3d38f7a0$1b00a8c0@sonyfrademeyer> Read the following documents: http://www.ethernut.de/pdf/entet100.pdf & http://www.ethernut.de/pdf/enmem100.pdf They contain a very good explanation. Do determine the excess stack memory, place the following logging code in the deepest function calls with most local variables: #include printf_P(PSTR("Free thread stack: %u\n"), (u_short) runningThread->td_sp - (u_short) runningThread->td_memory); In one of my projects I don't have external RAM due to shortage of pins (not even a single one!) and the use of a large graphic LCD. I have 4 threads and use 1 uart driver. With Nut-Os you really have to economise. I have stacks of SPI flash memory available (16Mbits) and if things get any tighter, I'm thinking about writing a mod that swaps the thread stack to flash. Now when will Atmel bring out an ATmega256 with 64K internal RAM? Probably never. When will someone have a port of Nut-Os ready for the ARM? GCC already has an ARM port, but the cost of developing for the ARM is very high. Yoda would have said: "Stuck between a rock and a hard place, I am.". Cheers, Francois ----- Original Message ----- From: "Gila" To: "Ethernut User Chat (English)" Sent: Tuesday, February 24, 2004 10:37 PM Subject: Re: [En-Nut-Discussion] Thread stack > On Tue, 2004-02-24 at 15:59, Francois Rademeyer wrote: > > Ignore the message, I have figured it out by now. > > Mind sharing it ? :) > > > > ----- Original Message ----- > > From: "Francois Rademeyer" > > To: "Ethernut User Chat (English)" > > Sent: Tuesday, February 24, 2004 3:15 PM > > Subject: [En-Nut-Discussion] Thread stack > > > > > > > Hi everyone, > > > > > > I have some stupid questions: > > > > > > Lately I have become very confused with all the GCC, AVR & NUT memories. > > I > > > am trying to find a good balance for the stack size specified when > > creating > > > threads. Except for all the registers that get pushed onto it when a > > thread > > > swap occurs, what else uses the thread stack? Unlike larger processors, > > > where local variables goes onto the stack, with the AVR they go into .bss > > > and .data, right? > > > > > > Thanks, > > > Francois > > > > > > > > > _______________________________________________ > > > En-Nut-Discussion mailing list > > > En-Nut-Discussion at egnite.de > > > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > > > > > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From damian at commtech.com.au Wed Feb 25 07:44:29 2004 From: damian at commtech.com.au (Damian Slee) Date: Wed, 25 Feb 2004 14:44:29 +0800 Subject: [En-Nut-Discussion] Http server - TCP state machine fix Message-ID: Hi all, Further to my email yesterday regarding occasionally SYN ACK not being received, I have traced that; - every SYN sent by the PC is received by ethernut - every SYN received in listening state has a SYN ACK generated. - NutIpOutput does Not fail in NutTcpOutput. So it should be passed all the way down to NicOutput() So it must be lost somewhere between NicOutput and received by the PC. This would be similar to the lost FIN of Dusan Ferbas findings. I put my money on it being lost by NicOutput/Realtek somewhere. -------------------- Moving on. I found that in tcpsm.c; - after a SYN is received, SYN ACK sent, switch to SYN RECEIVED state. Ok - SYN ACK disappears. Not so ok. - PC sends another SYN, after timeout of 3 and 6 seconds. Ok - Ethernut receives these SYNs in SYN RECEIVED STATE. ** the problem in NutTcpStateSynReceived() ** - this "without ACK" check is done before the Reject SYNs check. Therefore the Reject SYNs code will Never execute, cause the first handshake SYN from the PC doesn't have an ACK. Needs to be Swapped around. Result, a RST is sent imediately back to the PC, re-sync, page loads immediately. Should the same change apply to NutTcpStateFinWait1(), NutTcpStateFinWait2(), NutTcpStateCloseWait(), NutTcpStateClosing(), and NutTcpStateLastAck() ?? /* * Silently discard segments without ACK. */ if ((flags & TH_ACK) == 0) { NutNetBufFree(nb); return; } ... /* * Reject SYNs. */ if (flags & TH_SYN) { /* this code never executes, because of return above */ NutTcpReject(nb); return; } damian From damian at commtech.com.au Wed Feb 25 08:39:45 2004 From: damian at commtech.com.au (Damian Slee) Date: Wed, 25 Feb 2004 15:39:45 +0800 Subject: [En-Nut-Discussion] Http server - TCP state machine fix Message-ID: NicPutPacket() is definitely writing out the SYN ACK packet that is lost, so must be realtek or LAN loosing it. Will try crossover LAN cable tomorrow, ethernut direct to PC NIC. Eliminate any network switches etc... -----Original Message----- From: Damian Slee Sent: Wednesday, 25 February 2004 2:44 PM To: Ethernut User Chat (English) Subject: RE: [En-Nut-Discussion] Http server - TCP state machine fix Hi all, Further to my email yesterday regarding occasionally SYN ACK not being received, I have traced that; - every SYN sent by the PC is received by ethernut - every SYN received in listening state has a SYN ACK generated. - NutIpOutput does Not fail in NutTcpOutput. So it should be passed all the way down to NicOutput() So it must be lost somewhere between NicOutput and received by the PC. This would be similar to the lost FIN of Dusan Ferbas findings. I put my money on it being lost by NicOutput/Realtek somewhere. -------------------- Moving on. I found that in tcpsm.c; - after a SYN is received, SYN ACK sent, switch to SYN RECEIVED state. Ok - SYN ACK disappears. Not so ok. - PC sends another SYN, after timeout of 3 and 6 seconds. Ok - Ethernut receives these SYNs in SYN RECEIVED STATE. ** the problem in NutTcpStateSynReceived() ** - this "without ACK" check is done before the Reject SYNs check. Therefore the Reject SYNs code will Never execute, cause the first handshake SYN from the PC doesn't have an ACK. Needs to be Swapped around. Result, a RST is sent imediately back to the PC, re-sync, page loads immediately. Should the same change apply to NutTcpStateFinWait1(), NutTcpStateFinWait2(), NutTcpStateCloseWait(), NutTcpStateClosing(), and NutTcpStateLastAck() ?? /* * Silently discard segments without ACK. */ if ((flags & TH_ACK) == 0) { NutNetBufFree(nb); return; } ... /* * Reject SYNs. */ if (flags & TH_SYN) { /* this code never executes, because of return above */ NutTcpReject(nb); return; } damian _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From Oliver.Schulz at bong.de Wed Feb 25 08:40:05 2004 From: Oliver.Schulz at bong.de (Oliver Schulz) Date: Wed, 25 Feb 2004 08:40:05 +0100 Subject: AW: [En-Nut-Discussion] Thread stack Message-ID: Hi, also look here: http://www.egnite.de/pipermail/en-nut-discussion/2004-January/001769.html This separate interrupt stack will be included in Nut/OS 3.5 for avr-gcc only. It's already in the HEAD branch for testing. Cheers, Oliver. > -----Urspr?ngliche Nachricht----- > Von: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Francois > Rademeyer > Gesendet: Dienstag, 24. Februar 2004 14:16 > An: Ethernut User Chat (English) > Betreff: [En-Nut-Discussion] Thread stack > > > Hi everyone, > > I have some stupid questions: > > Lately I have become very confused with all the GCC, AVR & > NUT memories. I > am trying to find a good balance for the stack size specified > when creating > threads. Except for all the registers that get pushed onto > it when a thread > swap occurs, what else uses the thread stack? Unlike larger > processors, > where local variables goes onto the stack, with the AVR they > go into .bss > and .data, right? > > Thanks, > Francois > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From Oliver.Schulz at bong.de Wed Feb 25 08:47:55 2004 From: Oliver.Schulz at bong.de (Oliver Schulz) Date: Wed, 25 Feb 2004 08:47:55 +0100 Subject: AW: [En-Nut-Discussion] Http server - TCP state machine fix Message-ID: Hi Damian, some days ago, I tried to figure out why NutConnect sometimes get stucked. The reason was that the whole software stuff, including the realtek driver, reported success for sending the initial SYN TCP packet, but this packet was definitely not put on the LAN. My bugfix was, to use the retransmission timer for NutConnect, because the next packet was then transmitted correctly. But I didn't this testing again with the new driver from Bengan. While testing, I noticed a strange behaviour: If you put a 'NutDelay(1)' somewhere in NicPutPacket, everything seems to be ok then (except the performance, of course :-).... So long, Oliver. > -----Urspr?ngliche Nachricht----- > Von: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Damian Slee > Gesendet: Mittwoch, 25. Februar 2004 08:40 > An: Ethernut User Chat (English) > Betreff: RE: [En-Nut-Discussion] Http server - TCP state machine fix > > > NicPutPacket() is definitely writing out the SYN ACK packet that is > lost, so must be realtek or LAN loosing it. Will try crossover LAN > cable tomorrow, ethernut direct to PC NIC. Eliminate any network > switches etc... > > > -----Original Message----- > From: Damian Slee > Sent: Wednesday, 25 February 2004 2:44 PM > To: Ethernut User Chat (English) > Subject: RE: [En-Nut-Discussion] Http server - TCP state machine fix > > Hi all, > Further to my email yesterday regarding occasionally SYN ACK not being > received, I have traced that; > > - every SYN sent by the PC is received by ethernut > > - every SYN received in listening state has a SYN ACK generated. > > - NutIpOutput does Not fail in NutTcpOutput. So it should be > passed all > the way down to NicOutput() > > So it must be lost somewhere between NicOutput and received by the PC. > This would be similar to the lost FIN of Dusan Ferbas findings. I put > my money on it being lost by NicOutput/Realtek somewhere. > > -------------------- > Moving on. I found that in tcpsm.c; > - after a SYN is received, SYN ACK sent, switch to SYN RECEIVED state. > Ok > > - SYN ACK disappears. Not so ok. > > - PC sends another SYN, after timeout of 3 and 6 seconds. Ok > > - Ethernut receives these SYNs in SYN RECEIVED STATE. > > ** the problem in NutTcpStateSynReceived() ** > > - this "without ACK" check is done before the Reject SYNs check. > Therefore the Reject SYNs code will Never execute, cause the first > handshake SYN from the PC doesn't have an ACK. Needs to be Swapped > around. Result, a RST is sent imediately back to the PC, > re-sync, page > loads immediately. > > Should the same change apply to NutTcpStateFinWait1(), > NutTcpStateFinWait2(), NutTcpStateCloseWait(), > NutTcpStateClosing(), and > NutTcpStateLastAck() ?? > > > /* > * Silently discard segments without ACK. > */ > if ((flags & TH_ACK) == 0) { > NutNetBufFree(nb); > return; > } > ... > /* > * Reject SYNs. > */ > if (flags & TH_SYN) { > /* this code never executes, because of return above */ > NutTcpReject(nb); > return; > } > > > > damian > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From damian at commtech.com.au Wed Feb 25 09:14:19 2004 From: damian at commtech.com.au (Damian Slee) Date: Wed, 25 Feb 2004 16:14:19 +0800 Subject: [En-Nut-Discussion] Http server - TCP state machine fix Message-ID: Hi Oliver, I'm using the new driver with this problem. Tho I think it occurs in the old as well. Maybe there is another busy bit check or something needed. Do you agree with my NutTcpStateSynReceived() fix? Anyone, How does a call to NutTcpReject(), return it to a listening state? If there a FIN or something sent from the other end when they receive the RST? Thanks, damian -----Original Message----- From: Oliver Schulz [mailto:Oliver.Schulz at bong.de] Sent: Wednesday, 25 February 2004 3:48 PM To: Ethernut User Chat (English) Subject: AW: [En-Nut-Discussion] Http server - TCP state machine fix Hi Damian, some days ago, I tried to figure out why NutConnect sometimes get stucked. The reason was that the whole software stuff, including the realtek driver, reported success for sending the initial SYN TCP packet, but this packet was definitely not put on the LAN. My bugfix was, to use the retransmission timer for NutConnect, because the next packet was then transmitted correctly. But I didn't this testing again with the new driver from Bengan. While testing, I noticed a strange behaviour: If you put a 'NutDelay(1)' somewhere in NicPutPacket, everything seems to be ok then (except the performance, of course :-).... So long, Oliver. > -----Urspr?ngliche Nachricht----- > Von: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Damian Slee > Gesendet: Mittwoch, 25. Februar 2004 08:40 > An: Ethernut User Chat (English) > Betreff: RE: [En-Nut-Discussion] Http server - TCP state machine fix > > > NicPutPacket() is definitely writing out the SYN ACK packet that is > lost, so must be realtek or LAN loosing it. Will try crossover LAN > cable tomorrow, ethernut direct to PC NIC. Eliminate any network > switches etc... > > > -----Original Message----- > From: Damian Slee > Sent: Wednesday, 25 February 2004 2:44 PM > To: Ethernut User Chat (English) > Subject: RE: [En-Nut-Discussion] Http server - TCP state machine fix > > Hi all, > Further to my email yesterday regarding occasionally SYN ACK not being > received, I have traced that; > > - every SYN sent by the PC is received by ethernut > > - every SYN received in listening state has a SYN ACK generated. > > - NutIpOutput does Not fail in NutTcpOutput. So it should be passed > all the way down to NicOutput() > > So it must be lost somewhere between NicOutput and received by the PC. > This would be similar to the lost FIN of Dusan Ferbas findings. I put > my money on it being lost by NicOutput/Realtek somewhere. > > -------------------- > Moving on. I found that in tcpsm.c; > - after a SYN is received, SYN ACK sent, switch to SYN RECEIVED state. > Ok > > - SYN ACK disappears. Not so ok. > > - PC sends another SYN, after timeout of 3 and 6 seconds. Ok > > - Ethernut receives these SYNs in SYN RECEIVED STATE. > > ** the problem in NutTcpStateSynReceived() ** > > - this "without ACK" check is done before the Reject SYNs check. > Therefore the Reject SYNs code will Never execute, cause the first > handshake SYN from the PC doesn't have an ACK. Needs to be Swapped > around. Result, a RST is sent imediately back to the PC, re-sync, > page loads immediately. > > Should the same change apply to NutTcpStateFinWait1(), > NutTcpStateFinWait2(), NutTcpStateCloseWait(), NutTcpStateClosing(), > and > NutTcpStateLastAck() ?? > > > /* > * Silently discard segments without ACK. > */ > if ((flags & TH_ACK) == 0) { > NutNetBufFree(nb); > return; > } > ... > /* > * Reject SYNs. > */ > if (flags & TH_SYN) { > /* this code never executes, because of return above */ > NutTcpReject(nb); > return; > } > > > > damian > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From francois at asnone.com Wed Feb 25 13:33:34 2004 From: francois at asnone.com (Francois Rademeyer) Date: Wed, 25 Feb 2004 14:33:34 +0200 Subject: [En-Nut-Discussion] sscanf_P bug Message-ID: <079d01c3fb9b$95e82eb0$1b00a8c0@sonyfrademeyer> Just a bug I noticed: int sscanf_P(CONST char *string, CONST char *fmt, ...) should be int sscanf_P(CONST char *string, PGM_P fmt, ...) From francois at asnone.com Wed Feb 25 16:31:02 2004 From: francois at asnone.com (Francois Rademeyer) Date: Wed, 25 Feb 2004 17:31:02 +0200 Subject: [En-Nut-Discussion] Fw: scanf is very buggy! Message-ID: <07f301c3fbb4$6272c680$1b00a8c0@sonyfrademeyer> Attached is a new version for _getf that fixes two scanf bugs: 1) %% causes errors. 2) When an integer is parsed, the for loop steps 1 char too far at the end, which gives problems with subsequent parsing. 3) %u was not supported. Does anybody use scanf? -------------- next part -------------- A non-text attachment was scrubbed... Name: getf.zip Type: application/octet-stream Size: 3310 bytes Desc: not available URL: From lightfreakde at yahoo.com Wed Feb 25 17:21:18 2004 From: lightfreakde at yahoo.com (Simon Biniek) Date: Wed, 25 Feb 2004 08:21:18 -0800 (PST) Subject: [En-Nut-Discussion] Fw: scanf is very buggy! In-Reply-To: <07f301c3fbb4$6272c680$1b00a8c0@sonyfrademeyer> Message-ID: <20040225162118.86954.qmail@web13501.mail.yahoo.com> Hi, it is kwon, that scanf in general is not that good as expected. E.g. in Borlandc++ 3.1 the scanf function caused a program hang when you scan for an integer and typed in characters. Simon __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools From harald.kipp at egnite.de Wed Feb 25 17:56:29 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 25 Feb 2004 17:56:29 +0100 Subject: [En-Nut-Discussion] Fw: scanf is very buggy! In-Reply-To: <07f301c3fbb4$6272c680$1b00a8c0@sonyfrademeyer> Message-ID: <5.1.1.6.0.20040225175028.032e21e0@egnite.de> I guess, Oliver will take care of this. Possible reason for all these bugs: I never liked scanf, but agree, that it's very powerful when reading files. Many thanks. I just committed several changes to HEAD: * dev/debug*.c: Added ioctl baudrate support. * dev/lanc111.c, net/ifconfig.c: Avoid chip initialization with MAC address zero. This is a quick hack for all this init mess. * include/pro/dhcp.h: Added NutDhcpRelease prototype. * pro/dhcpc.c: New API added to relinguish the DHCP lease. Collecting more than one offer is now disabled, if the application sets timeout below three times of MAX_DHCP_WAIT (5 seconds). The lease renewal will now start when 3/4 has elapsed, opposed to 1/2 used previously. Finally the DHCP thread will sleep as long as possible, while the previous version woke up every ten seconds. DHCP is now kind of snappier. Harald At 17:31 25.02.2004 +0200, you wrote: > Attached is a new version for _getf that fixes two scanf bugs: > > 1) %% causes errors. >2) When an integer is parsed, the for loop steps 1 char too far at the end, >which gives problems with subsequent parsing. >3) %u was not supported. > > Does anybody use scanf? > From olischulz at web.de Wed Feb 25 20:22:33 2004 From: olischulz at web.de (Oliver Schulz) Date: Wed, 25 Feb 2004 20:22:33 +0100 Subject: AW: [En-Nut-Discussion] Fw: scanf is very buggy! In-Reply-To: <5.1.1.6.0.20040225175028.032e21e0@egnite.de> Message-ID: <000901c3fbd4$b8c36ec0$5b42a8c0@ose.de> Hi! > I guess, Oliver will take care of this. I will do as soon as I can. > Possible reason for all these bugs: I never liked > scanf, but agree, that it's very powerful when reading Yes, I didn't use it very often, but never so far in Nut/OS... Strange, that nobody noticed it before .-) > > > > Does anybody use scanf? > > ... that's the question ;-) Cheers, Oliver. From fischermi at t-online.de Wed Feb 25 21:25:29 2004 From: fischermi at t-online.de (Michael Fischer) Date: Wed, 25 Feb 2004 21:25:29 +0100 Subject: [En-Nut-Discussion] Ethernut 2 AddressRange? Message-ID: Hello, does anybody know if the address range from 0xFFF0 to 0xFFFF is free for an IO card on Ethernut2? Regards, Michael From olischulz at web.de Wed Feb 25 23:51:41 2004 From: olischulz at web.de (Oliver Schulz) Date: Wed, 25 Feb 2004 23:51:41 +0100 Subject: AW: [En-Nut-Discussion] Http server - TCP state machine fix In-Reply-To: Message-ID: <000001c3fbf1$f00a41c0$5b42a8c0@ose.de> Hi Damian, regarding your found bug in NutTcpStateSynReceived (and perhaps in NutTcpStateFinWait1(), NutTcpStateFinWait2(), NutTcpStateCloseWait(), NutTcpStateClosing() and NutTcpStateLastAck()), I have to take some time to look again at these big tcp state machine to be sure not to add some more side effects... But on the first look, I would say you're right. So long, Oliver. > -----Urspr?ngliche Nachricht----- > Von: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Damian Slee > Gesendet: Mittwoch, 25. Februar 2004 09:14 > An: Ethernut User Chat (English) > Betreff: RE: [En-Nut-Discussion] Http server - TCP state machine fix > > > Hi Oliver, > I'm using the new driver with this problem. Tho I think it > occurs in the old as well. > Maybe there is another busy bit check or something needed. > > Do you agree with my NutTcpStateSynReceived() fix? > > Anyone, > How does a call to NutTcpReject(), return it to a listening state? > If there a FIN or something sent from the other end when they > receive the RST? > > Thanks, > > damian > > -----Original Message----- > From: Oliver Schulz [mailto:Oliver.Schulz at bong.de] > Sent: Wednesday, 25 February 2004 3:48 PM > To: Ethernut User Chat (English) > Subject: AW: [En-Nut-Discussion] Http server - TCP state machine fix > > Hi Damian, > > some days ago, I tried to figure out why NutConnect sometimes > get stucked. > The reason was that the whole software stuff, including the > realtek driver, reported success for sending the initial SYN > TCP packet, but this packet was definitely not put on the LAN. > > My bugfix was, to use the retransmission timer for > NutConnect, because the next packet was then transmitted correctly. > But I didn't this testing again with the new driver from Bengan. > > While testing, I noticed a strange behaviour: If you put a > 'NutDelay(1)' somewhere in NicPutPacket, everything seems to > be ok then (except the performance, of course :-).... > > So long, > Oliver. > [snip] -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2852 bytes Desc: not available URL: From damian at commtech.com.au Thu Feb 26 10:44:45 2004 From: damian at commtech.com.au (Damian Slee) Date: Thu, 26 Feb 2004 17:44:45 +0800 Subject: [En-Nut-Discussion] Realtek driver fix for Tx packet loss Message-ID: Will give more details on the fix tommorrow after some more testing. Here are my findings after lots of debuging and tracing today; - I haven't applied the TCP SM fix from yesterday, so I could use the browser page load fail as a visual indication of the SYN ACK packet being dropped on Tx from realtek. I eventually found that when ever I had a html page fail to load, that an NicInterrupt() was being generated with interrupt status register (ISR) bit NIC_ISR_RXE (receive error bit) being set. This corresponded very very closely to the point in time where the SYN ACK was failing to be transmitted. I was also getting the ISR receive error bit set at some other times. These turned out later to be at the same time other packets where being dropped. Some FIN packets, and data packets. Traced the cause of the receive error through the receive status register to be DFR bit (0x80) in receive status register. "Defferring. Set when a carrier or a collision is detected." Not sure why it still happens on a crossover LAN cable PC<->Ethernut. After a lot more tracing, I found that if I read the receive status register straight after "Start transmission", the times it failed the DFR bit was set. Further to this, the transmit start bit TXP in command register, gets reset back to 0, indicating "transmission is completed or aborted". I tried checking TXP bit on its own, but it seems I had to read the receive status register first? Either that or it needs a nop or two before checking TXP after a start transmission(tomorrow). I have implemented a retry, which when detecting the above, simply does a start transmission again, do..while(failed) kinda thing. Occasionally it has retried twice. I have tested this to the point where I get some debug output (RS232) when the retries occur, and capturing with etherreal. Where the retries occur, I am inspecting ethereal for duplicate or missing packets. Seems to be No duplicates, and No missing packets. More tomorrow, damn I'm hungry cause I missed lunch. From chromy at asix.cz Fri Feb 27 09:34:58 2004 From: chromy at asix.cz (Pavel Chromy) Date: Fri, 27 Feb 2004 09:34:58 +0100 Subject: [En-Nut-Discussion] fflush on input Message-ID: <403F0132.8040904@asix.cz> > I use fflush to ensure the output goes to destination but I wouldnt want > to lose incoming data already queued just because the output thread > wanted to hurry up.... How should I be forcing output buffer to flush > without affecting incoming stream data? > Message: 4 > Date: Thu, 11 Dec 2003 15:08:28 +0100 > From: Harald Kipp > Subject: Re: [En-Nut-Discussion] fflush newbie question > To: togrady at comtech.uk.com, "Ethernut User Chat (English)" > > Message-ID: <5.1.1.6.0.20031211150609.02d48d18 at egnite.de> > Content-Type: text/plain; charset="us-ascii"; format=flowed > > fflush forces data output only. It does not flush the input > buffer, which is considered an error and will be changed. > > fflush shall force output and discard the input. I bit outdated reply: I think this that discarding output in fflush is a bad idea as Brett pointed out. There might be a separate function discarding input, which is usually called purge (probably fpurge?). Pavel From eeaj2002 at yahoo.com Thu Feb 26 19:52:29 2004 From: eeaj2002 at yahoo.com (john Mcdonald) Date: Thu, 26 Feb 2004 10:52:29 -0800 (PST) Subject: [En-Nut-Discussion] Optrex F-51553 LCD display Message-ID: <20040226185229.20543.qmail@web14807.mail.yahoo.com> This message is for Michael G. Svob, Hi Micheal, Can I have a copy of the code you wrote for F-51553 optrex display please. Thanks, John. --------------------------------- Do you Yahoo!? Get better spam protection with Yahoo! Mail -------------- next part -------------- An HTML attachment was scrubbed... URL: From Oliver.Schulz at bong.de Fri Feb 27 10:04:33 2004 From: Oliver.Schulz at bong.de (Oliver Schulz) Date: Fri, 27 Feb 2004 10:04:33 +0100 Subject: AW: [En-Nut-Discussion] fflush on input Message-ID: Hi, to finally clearify this fflush issue: By calling 'fflush', the device's write function is called with parameter 'len' set to zero. It's up to the device driver to handle this special write. The USART device driver and TCPSOCKET virtual device will then sent any buffered output data to the device output function. That means output buffers are flushed, but NOT discarded. The input buffer is NOT touched in any manner, means that it is also NOT discarded. Actually there is no function to discard input buffers, but IMHO it would be nice to have one. I will look how to implement 'fpurge' this weekend (and commitin' some other queued bugfixes to CVS). Regards, Oliver. > -----Urspr?ngliche Nachricht----- > Von: en-nut-discussion-bounces at egnite.de > [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von > Pavel Chromy > Gesendet: Freitag, 27. Februar 2004 09:35 > An: Ethernut User Chat (English) > Betreff: Re: [En-Nut-Discussion] fflush on input > > > > > I use fflush to ensure the output goes to destination but I > wouldnt want > > to lose incoming data already queued just because the output thread > > wanted to hurry up.... How should I be forcing output > buffer to flush > > without affecting incoming stream data? > > > Message: 4 > > Date: Thu, 11 Dec 2003 15:08:28 +0100 > > From: Harald Kipp > > Subject: Re: [En-Nut-Discussion] fflush newbie question > > To: togrady at comtech.uk.com, "Ethernut User Chat (English)" > > > > Message-ID: <5.1.1.6.0.20031211150609.02d48d18 at egnite.de> > > Content-Type: text/plain; charset="us-ascii"; format=flowed > > > > fflush forces data output only. It does not flush the input > > buffer, which is considered an error and will be changed. > > > > fflush shall force output and discard the input. > > I bit outdated reply: > I think this that discarding output in fflush is a bad idea > as Brett pointed out. > There might be a separate function discarding input, which is > usually called > purge (probably fpurge?). > > Pavel > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion > From damian at commtech.com.au Fri Feb 27 10:31:12 2004 From: damian at commtech.com.au (Damian Slee) Date: Fri, 27 Feb 2004 17:31:12 +0800 Subject: [En-Nut-Discussion] My latest usartavr.c Message-ID: - When selecting software flow control, XON will be sent on next read, if low water mark is reached. - when XOFF received, transmitter now stops. - #define UART_HDX_FLIP_BIT to invert the polarity of the half duplex pin. This makes it the same polarity as RTS Toggle done by the Windows NT comms driver. damian -------------- next part -------------- A non-text attachment was scrubbed... Name: usartavr.zip Type: application/x-zip-compressed Size: 6644 bytes Desc: usartavr.zip URL: From gedas at tvk.lt Fri Feb 27 10:35:37 2004 From: gedas at tvk.lt (Gediminas Simanskis) Date: Fri, 27 Feb 2004 11:35:37 +0200 Subject: [En-Nut-Discussion] Netgear wireless 802.11b PCMCIA card References: Message-ID: <000501c3fd15$0eaff920$0a00000a@p350> Does anybody have intersil PRISM Driver Programmer's Manual ? From ceba at vabo.cz Fri Feb 27 11:40:07 2004 From: ceba at vabo.cz (Pavel Celeda) Date: Fri, 27 Feb 2004 11:40:07 +0100 Subject: [En-Nut-Discussion] Ethernut network configuration bug Message-ID: <1077878406.2417.47.camel@hw.vabo.cz> This week I have discovered racecondition during setting up eth0 network configuration. This bug affects both static eeprom and dhcp configuration. Nut/OS version 3.4.1.1 - CVS snapshot Initial situation: Ethernut I. board with static eeprom configuration. Device is UP and runnig on the local network. PC1(Linux) ----> router ----> Ethernut I. (IP1) ping IP1, everything works fine. Ping is running continually. 1) static eeprom configuration I change Ethernut's IP addres (IP1->IP2) via serial terminal and save it to the eeprom - NutNetSaveConfig(). Now I press reset button and the Ethernut starts with IP1 instead with IP2. I use following procedure for configuring eth0 device. NutNetLoadConfig(); NutRegisterDevice(); ... configuration racecondition in NutIpInput() ... NutNetIfConfig(); NutIpRouteAdd(); ICMP datagrams are still comming from PC1. I have discovered that NutIpInput() contains code which calls NutNetIfSetup() and this piece of code kill my previous eeprom configuration (IP2->IP1 and discards rest of network configuration). I known "That's not a bug, that's a feature" used to setup IP address via dynamic IP ARP method. But I thing nowadays when we can use dhcp for setting up network configuration this feature should be by default disabled. 2) dhcp configuration The same configuration (PC1, router, Ethernut). Ethernut will get IP address from dhcp server (FreeBSD - ISC DHCPv3.0.1rc11) on the same local network segment. Now I start ping IP1 and press reset on Ethernut board. NetDhcpIfConfig fails and I can't obtain valid configuration from dhcp server. I patched the NutIpInput() and removed the code with NutNetIfSetup() and now everything works fine. with best regards Pavel From damian at commtech.com.au Fri Feb 27 12:18:23 2004 From: damian at commtech.com.au (Damian Slee) Date: Fri, 27 Feb 2004 19:18:23 +0800 Subject: [En-Nut-Discussion] My latest usartavr.c Message-ID: - and enables tx complete interrupt for half duplex mode, when you use SetFlowControl(). -----Original Message----- From: Damian Slee Sent: Fri 27/02/2004 5:31 PM To: Ethernut User Chat (English) Cc: Subject: [En-Nut-Discussion] My latest usartavr.c - When selecting software flow control, XON will be sent on next read, if low water mark is reached. - when XOFF received, transmitter now stops. - #define UART_HDX_FLIP_BIT to invert the polarity of the half duplex pin. This makes it the same polarity as RTS Toggle done by the Windows NT comms driver. damian -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 4030 bytes Desc: not available URL: From harald.kipp at egnite.de Fri Feb 27 12:28:47 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Fri, 27 Feb 2004 12:28:47 +0100 Subject: [En-Nut-Discussion] Netgear wireless 802.11b PCMCIA card In-Reply-To: Message-ID: <5.1.1.6.0.20040227122145.01bd9508@egnite.de> Hi, I rejected a response from Jean Pierre, because 1. Large attachments will spoil our archive. 2. Not all subscribers are prepared to receive monster emails. 3. The distribution of this NDA protected document might be illegal (but I do not know for sure). Anyway, thanks for your help, Jean Pierre. Please pass the document directly to Gediminas Simanskis gedas at tvk dot lt Regards, Harald From harald.kipp at egnite.de Fri Feb 27 12:53:24 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Fri, 27 Feb 2004 12:53:24 +0100 Subject: [En-Nut-Discussion] Ethernut network configuration bug In-Reply-To: <1077878406.2417.47.camel@hw.vabo.cz> Message-ID: <5.1.1.6.0.20040227123431.032bfea8@egnite.de> Hi Pavel, I do not fully agree. I'm aware that this race condition exists, but I think you fixed it too easily. Two reasons: 1. Many Ethernut users still do not have DHCP. 2. The race condition appears only, if you ping a configured Ethernut, reset the Ethernut while pinging and trying to assign a new IP address. Otherwise the pinging host will send an ARP request first. Since the Ethernuts are equipped with ATmega128 chips with retain-EEPROM fuse, the situation is better, but we still have many users of ATMega103 Ethernuts. I may accept to limit the ARP method to ATmega103 systems. Simply removing it for the rare condition you described would leave others in the rain. And I need to update the docs (which needs to be done anyway, I know). Nevertheless, DHCP should not fail. This is indeed an issue. Regards, Harald From jesperh at telia.com Fri Feb 27 14:32:41 2004 From: jesperh at telia.com (Jesper Hansen) Date: Fri, 27 Feb 2004 14:32:41 +0100 Subject: [En-Nut-Discussion] Netgear wireless 802.11b PCMCIA card References: <5.1.1.6.0.20040227122145.01bd9508@egnite.de> Message-ID: <01af01c3fd36$32ce7b80$6500a8c0@jeha> I can't help breaking in here, and say that, as I'm working on 802.11 support too, I would VERY much appreciate a copy of this document too, Jean Pierre !! /Jesper ----- Original Message ----- From: "Harald Kipp" To: Sent: Friday, February 27, 2004 12:28 PM Subject: [En-Nut-Discussion] Netgear wireless 802.11b PCMCIA card > Hi, > > I rejected a response from Jean Pierre, because > > 1. Large attachments will spoil our archive. > 2. Not all subscribers are prepared to receive monster emails. > 3. The distribution of this NDA protected document might be > illegal (but I do not know for sure). > > Anyway, thanks for your help, Jean Pierre. Please pass the > document directly to Gediminas Simanskis gedas at tvk dot lt > > Regards, > > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From zodianet at wanadoo.fr Fri Feb 27 14:37:29 2004 From: zodianet at wanadoo.fr (Zodianet) Date: Fri, 27 Feb 2004 14:37:29 +0100 Subject: [En-Nut-Discussion] NutDnsGetHostByName bug ? In-Reply-To: <5.1.1.6.0.20040227123431.032bfea8@egnite.de> Message-ID: <20040227133941.9D6FB18001AD@mwinf0801.wanadoo.fr> NutDnsGetHostByName (resolv.c) seems to not release correctly memory alloc, "doq->doq_name" in CreateDnsQuestion function. A single but not very elegant test "if (doq->doq_name) NutHeapFree(doq->doq_name)" seems suppress this bug. Jean Pierre static DNSQUESTION *CreateDnsQuestion(DNSQUESTION * doq, CONST u_char * name) { if (doq == 0) doq = NutHeapAllocClear(sizeof(DNSQUESTION)); if (doq) { if (doq->doq_name) // <--------- NutHeapFree(doq->doq_name); // <---------- doq->doq_name = NutHeapAlloc(strlen(name) + 1); strcpy(doq->doq_name, name); doq->doq_type = 1; doq->doq_class = 1; } From zodianet at wanadoo.fr Fri Feb 27 17:07:47 2004 From: zodianet at wanadoo.fr (Zodianet) Date: Fri, 27 Feb 2004 17:07:47 +0100 Subject: [En-Nut-Discussion] RE: [En-Nut-Discussion ] Prism Manual link for anybody... In-Reply-To: <01af01c3fd36$32ce7b80$6500a8c0@jeha> Message-ID: <20040227160959.6FF111800055@mwinf0804.wanadoo.fr> http://home.kpnqwest.cz/jt/wifi/RM0251.pdf I think this link (found after 7'' with Google "RM0251 prim") is not under NDA ;-) I agree, it's too easy to find this document with its name :-) Jean Pierre -----Message d'origine----- De : en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de] De la part de Jesper Hansen Envoy? : vendredi 27 f?vrier 2004 14:33 ? : Ethernut User Chat (English) Objet : Re: [En-Nut-Discussion] Netgear wireless 802.11b PCMCIA card I can't help breaking in here, and say that, as I'm working on 802.11 support too, I would VERY much appreciate a copy of this document too, Jean Pierre !! /Jesper ----- Original Message ----- From: "Harald Kipp" To: Sent: Friday, February 27, 2004 12:28 PM Subject: [En-Nut-Discussion] Netgear wireless 802.11b PCMCIA card > Hi, > > I rejected a response from Jean Pierre, because > > 1. Large attachments will spoil our archive. > 2. Not all subscribers are prepared to receive monster emails. > 3. The distribution of this NDA protected document might be > illegal (but I do not know for sure). > > Anyway, thanks for your help, Jean Pierre. Please pass the > document directly to Gediminas Simanskis gedas at tvk dot lt > > Regards, > > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From harald.kipp at egnite.de Fri Feb 27 18:36:47 2004 From: harald.kipp at egnite.de (Harald Kipp) Date: Fri, 27 Feb 2004 18:36:47 +0100 Subject: [En-Nut-Discussion] RE: [En-Nut-Discussion ] Prism Manual link for anybody... In-Reply-To: <20040227160959.6FF111800055@mwinf0804.wanadoo.fr> References: <01af01c3fd36$32ce7b80$6500a8c0@jeha> Message-ID: <5.1.1.6.0.20040227182710.0335aec0@egnite.de> Jean Pierre, you wrote > I think this link (found after 7'' with Google "RM0251 prim") is not under > NDA ;-) The very first sentence clearly states: "For distribution under a Non-Disclosure Agreement only." The imprint for www.ethernut.de also clearly states "egnite Software GmbH assumes no responsibility for the contents of web sites that can be accessed through such links." If "Mr. Prism" calls me on Monday, I'll pass him to you. :-) No, seriously. This link may become a problem for home.kpnqwest.cz and anybody else who hosts this file for public access. It depends, of course, on local laws. But I wouldn't add it to the Ethernut download area. Harald From zodianet at wanadoo.fr Fri Feb 27 20:00:39 2004 From: zodianet at wanadoo.fr (Zodianet) Date: Fri, 27 Feb 2004 20:00:39 +0100 Subject: [En-Nut-Discussion] RE: [En-Nut-Discussion ] Prism Manuallink for anybody... In-Reply-To: <5.1.1.6.0.20040227182710.0335aec0@egnite.de> Message-ID: <20040227190251.A4D4818000C5@mwinf0802.wanadoo.fr> Please, Harald, pass Mr Prism to home.kpnqwest.cz, not me ;-) home.kpnqwest.cz takes his responsability. Of course, do not host this file yourself, without add-value. (Even if in fact, Prism 2.0... 3 chips are old and NDA has no meaning today). Jean Pierre -----Message d'origine----- De : en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-bounces at egnite.de] De la part de Harald Kipp Envoy? : vendredi 27 f?vrier 2004 18:37 ? : Ethernut User Chat (English) Objet : Re: [En-Nut-Discussion] RE: [En-Nut-Discussion ] Prism Manuallink for anybody... Jean Pierre, you wrote > I think this link (found after 7'' with Google "RM0251 prim") is not under > NDA ;-) The very first sentence clearly states: "For distribution under a Non-Disclosure Agreement only." The imprint for www.ethernut.de also clearly states "egnite Software GmbH assumes no responsibility for the contents of web sites that can be accessed through such links." If "Mr. Prism" calls me on Monday, I'll pass him to you. :-) No, seriously. This link may become a problem for home.kpnqwest.cz and anybody else who hosts this file for public access. It depends, of course, on local laws. But I wouldn't add it to the Ethernut download area. Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From jesperh at telia.com Fri Feb 27 20:10:05 2004 From: jesperh at telia.com (Jesper Hansen) Date: Fri, 27 Feb 2004 20:10:05 +0100 Subject: [En-Nut-Discussion] RE: [En-Nut-Discussion ] Prism Manuallink foranybody... References: <20040227190251.A4D4818000C5@mwinf0802.wanadoo.fr> Message-ID: <025901c3fd65$63b7cce0$6500a8c0@jeha> > (Even if in fact, Prism 2.0... 3 chips are old and NDA has no meaning > today). > Jean Pierre That's what we would like to think. Last year, I needed to buy 200.000 cards for a project and asked Intersil if I could sign the NDA and get the document. Obviously, this was completely impossible. Sadly, as such a treatment would make me happy to change to another chipset, the situation is the same, so I'm stuck with the Prism2, due to the availability of Linux drivers, code from IOSoft and the now sudden appearance of this document. So they get to sell the chips anyway :-( /Jesper From zodianet at wanadoo.fr Fri Feb 27 21:59:43 2004 From: zodianet at wanadoo.fr (Zodianet) Date: Fri, 27 Feb 2004 21:59:43 +0100 Subject: [En-Nut-Discussion] RE: [En-Nut-Discussion ] Prism Manuallinkforanybody... In-Reply-To: <025901c3fd65$63b7cce0$6500a8c0@jeha> Message-ID: <20040227210156.4E71A1800195@mwinf0802.wanadoo.fr> Yes, I remarked that too. Incredible. 802.11 chip-sets world appairs very "closed" ... and too closed to PC mass market and subject to Asian copies. Perhaps, Broadcom will follow (http://www.broadcom.com/products/category.php?category_id=40) another marketing strategy? JP That's what we would like to think. Last year, I needed to buy 200.000 cards for a project and asked Intersil if I could sign the NDA and get the document. Obviously, this was completely impossible. Sadly, as such a treatment would make me happy to change to another chipset, the situation is the same, so I'm stuck with the Prism2, due to the availability of Linux drivers, code from IOSoft and the now sudden appearance of this document. So they get to sell the chips anyway :-( /Jesper _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion From olischulz at web.de Sat Feb 28 21:41:14 2004 From: olischulz at web.de (Oliver Schulz) Date: Sat, 28 Feb 2004 21:41:14 +0100 Subject: [En-Nut-Discussion] Bugfixes from today In-Reply-To: <20040227133941.9D6FB18001AD@mwinf0801.wanadoo.fr> Message-ID: <000801c3fe3b$35f28e40$5b42a8c0@ose.de> Hello all, I just commited some bugfixes to nut-3_4-release and HEAD into CVS: * net/tcpsm.c: Bugfix in several tcp state functions. Swapped around the check for ACK and SYN flag. Because initial SYN packets don't have an ACK flag, recevied SYN packets were never rejected. This bug was discovered by Damian Slee. It seems, that tcp stack is now more reliable. Heavily stressed httpd application doesn't loose tcp sockets any more. * pro/resolv.c: Memory leak fixed in CreateDnsQuestion. Bugfix by Jean Pierre Gauthier. On re-creating the structure for dns question, some previously allocated memory was not released. * crt/getf.c: Several bugfixes from Francois Rademeyer applied. - "%%" didn't work. - integer parsing corrected. - support for "%u". Many thanks to all the authors and testers, who help us to build a reliable Nut/OS!!! Cheers, Oliver.