[ECOS] ecos + lwip

[ECOS] ecos + lwip

[Mandeep Sandhu]

Hi all,

I'm writing my app which makes use of the lwIP stack to send/recv packets.

I'm using lwIP that comes along with ecos-3.0 (which I think is ver 1.1.1).

I started by looking at the "test" examples given with lwIP. I noticed
that ALL examples
create 2 threads. One which simply starts and calls the following
functions and exits:

lwip_init();
sys_thread_new(...)

The thread started as part of sys_thread_new does the main
functionality of the app.
From the source I saw that sys_thread_new() simply allocates resources necessary
for starting the lwIP stack and then schedules the user function for execution.

My question:

* Does the lwIP stack run within the context of the thread started by
sys_thread_new()?

* If my app has to start 2 threads, both creating separate sockets and
send/recv data over
  it, then should only one of them be created with a call to
sys_thread_new()? While the other
  one is started by our regular cyg_thread_create() and friends?

Sorry if this is a dumb question.

Thanks,
-mandeep

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Simon Kallweit]

Mandeep Sandhu wrote:
> Hi all,
> 
> I'm writing my app which makes use of the lwIP stack to send/recv packets.
> 
> I'm using lwIP that comes along with ecos-3.0 (which I think is ver 1.1.1).
> 
> I started by looking at the "test" examples given with lwIP. I noticed
> that ALL examples
> create 2 threads. One which simply starts and calls the following
> functions and exits:
> 
> lwip_init();
> sys_thread_new(...)
> 
> The thread started as part of sys_thread_new does the main
> functionality of the app.
> From the source I saw that sys_thread_new() simply allocates resources necessary
> for starting the lwIP stack and then schedules the user function for execution.
> 
> My question:
> 
> * Does the lwIP stack run within the context of the thread started by
> sys_thread_new()?

No, lwip runs in a thread created in lwip_init(), which is called the 
'tcpip thread' (lwip naming). The name is a bit misleading, as it 
handles more than just tcpip, it's more like a central message queue 
handler which syncs the different threads of the application to the 
stack. The stack is not thread-safe by itself. The netcomm and socket 
APIs thus use a message queue to communicate to the tcpip thread.

> * If my app has to start 2 threads, both creating separate sockets and
> send/recv data over
>   it, then should only one of them be created with a call to
> sys_thread_new()? While the other
>   one is started by our regular cyg_thread_create() and friends?

Threads that use lwip APIs (netcomm and sockets) *must* be created with 
  sys_new_thread(). Otherwise lwip's timeout mechanism will not work as 
expected.

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Mandeep Sandhu]

> Threads that use lwip APIs (netcomm and sockets) *must* be created with
>  sys_new_thread(). Otherwise lwip's timeout mechanism will not work as
> expected.

Thanks for this info Simon.

I'm stuck at how to pass an app supplied arg to my threads start function that's
created using sys_thread_new().

I want to pass an arg to my threads start function. I think the 2nd arg to
sys_thread_new() seems to be user supplied arg, but from the usage I've seen
that apps usually pass the thread's name to it in the 2nd arg.

Internally, sys_thread_new uses this 2nd arg for both the name as well as the
arg to the start function while calling cyg_thread_create(). So is there no way
I can pass an arg to it (apart from the name)?

Thanks,
-mandeep

>
> Simon
>

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Simon Kallweit]

Mandeep Sandhu wrote:
>> Threads that use lwip APIs (netcomm and sockets) *must* be created with
>>  sys_new_thread(). Otherwise lwip's timeout mechanism will not work as
>> expected.
> 
> Thanks for this info Simon.
> 
> I'm stuck at how to pass an app supplied arg to my threads start function that's
> created using sys_thread_new().
> 
> I want to pass an arg to my threads start function. I think the 2nd arg to
> sys_thread_new() seems to be user supplied arg, but from the usage I've seen
> that apps usually pass the thread's name to it in the 2nd arg.
> 
> Internally, sys_thread_new uses this 2nd arg for both the name as well as the
> arg to the start function while calling cyg_thread_create(). So is there no way
> I can pass an arg to it (apart from the name)?

The implementation seems broken. I see three workarounds here:

1. Change the implementation to *not* use the user arg as the threads 
name, but provide a dummy name to cyg_create_thread() instead.
2. Define a struct with the first field being a dummy name, followed by 
any other fields you need and hand a pointer to this struct to 
sys_thread_new().
3. Use my new lwip port, which hopefully will soon be merged with eCos 
CVS. In the new release, sys_thread_new() takes both a thread name and a 
user argument, and uses them appropriately. Here is a preview release of 
lwip 1.3.1 for eCos. Just copy all the files in the archive over the 
eCos repository.

http://download.westlicht.ch/lwip-20090827.tar.gz

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Mandeep Sandhu]

> 3. Use my new lwip port, which hopefully will soon be merged with eCos CVS.
> In the new release, sys_thread_new() takes both a thread name and a user
> argument, and uses them appropriately. Here is a preview release of lwip

I prefer this approach. Much cleaner and as one would expect.

> 1.3.1 for eCos. Just copy all the files in the archive over the eCos
> repository.
>
> http://download.westlicht.ch/lwip-20090827.tar.gz

Thanks. I'll try it out and let you know if I face any issues.

Regards,
-mandeep

>
> Simon
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Mandeep Sandhu]

>> 1.3.1 for eCos. Just copy all the files in the archive over the eCos
>> repository.
>>
>> http://download.westlicht.ch/lwip-20090827.tar.gz
Hi Simon,

I tried building a new linux synth target with the lwip_sequential package
selected (using the ecos supplied i386-elf GCC).

I ran into some errors when I try ti build the target.

First there was a missing bracket in
packages/net/lwip_tcpip/current/src/core/ipv4/ip.c
Line 413.

After fixing that, I get a bunch of errors:

Wall -Wpointer-arith -Wstrict-prototypes -Wundef  -Wno-write-strings
-g -O2 -ffunction-sections -fdata-sections  -fno-exceptions
-fno-stack-protector -Wp,-MD,src/api/tcpip.tmp -o
src/api/net_lwip_tcpip_tcpip.o
/home/mandeep/ecos/ecos-3.0/packages/net/lwip_tcpip/current/src/api/tcpip.c
/home/mandeep/ecos/ecos-3.0/packages/net/lwip_tcpip/current/src/api/sockets.c:1241:
warning: overflow in implicit constant conversion
/home/mandeep/ecos/ecos-3.0/packages/net/lwip_tcpip/current/src/api/sockets.c:1249:
warning: overflow in implicit constant conversion
/home/mandeep/ecos/ecos-3.0/packages/net/lwip_tcpip/current/src/api/sockets.c:1281:
warning: overflow in implicit constant conversion
/home/mandeep/ecos/ecos-3.0/packages/net/lwip_tcpip/current/src/api/sockets.c:1310:
warning: overflow in implicit constant conversion
/home/mandeep/ecos/ecos-3.0/packages/net/lwip_tcpip/current/src/api/sockets.c:1334:
warning: overflow in implicit constant conversion
/home/mandeep/ecos/ecos-3.0/packages/net/lwip_tcpip/current/src/api/sockets.c:1342:
warning: overflow in implicit constant conversion
/home/mandeep/ecos/ecos-3.0/packages/net/lwip_tcpip/current/src/api/sockets.c:
In function ‘lwip_setsockopt_internal’:
/home/mandeep/ecos/ecos-3.0/packages/net/lwip_tcpip/current/src/api/sockets.c:1841:
warning: overflow in implicit constant conversion
...
/home/mandeep/ecos/ecos-3.0/packages/net/lwip_tcpip/current/src/ecos/sequential.c:113:
warning: ‘set_ip_addr’ defined but not used
...
...
/home/mandeep/ecos/ecos-3.0/packages/net/lwip_tcpip/current/src/ecos/sio.c:61:29:
error: cyg/io/serialio.h: No such file or directory
/home/mandeep/ecos/ecos-3.0/packages/net/lwip_tcpip/current/src/ecos/sio.c:
In function ‘sio_tryread’:
/home/mandeep/ecos/ecos-3.0/packages/net/lwip_tcpip/current/src/ecos/sio.c:169:
error: ‘cyg_serial_buf_info_t’ undeclared (first use in this function)
/home/mandeep/ecos/ecos-3.0/packages/net/lwip_tcpip/current/src/ecos/sio.c:169:
error: (Each undeclared identifier is reported only once
/home/mandeep/ecos/ecos-3.0/packages/net/lwip_tcpip/current/src/ecos/sio.c:169:
error: for each function it appears in.)
/home/mandeep/ecos/ecos-3.0/packages/net/lwip_tcpip/current/src/ecos/sio.c:169:
error: expected ‘;’ before ‘info’
/home/mandeep/ecos/ecos-3.0/packages/net/lwip_tcpip/current/src/ecos/sio.c:177:
error: ‘info’ undeclared (first use in this function)
make[1]: *** [src/ecos/sio.o.d] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory
`/home/mandeep/ecos/lwip-131/lwip-131_build/net/lwip_tcpip/current'
make: *** [build] Error 2
make: Leaving directory `/home/mandeep/ecos/lwip-131/lwip-131_build'

I'm sure this port compiles fine but somehow my build seems to be
missing something. I've checked and I have
the serialio.h file

$ find packages/ -name serialio.h
packages/io/serial/v3_0/include/serialio.h
$

Also, are the warnings expected?

Thanks,
-mandeep


>
> Thanks. I'll try it out and let you know if I face any issues.
>
> Regards,
> -mandeep
>
>>
>> Simon
>>
>

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Simon Kallweit]

Mandeep Sandhu wrote:
>>> 1.3.1 for eCos. Just copy all the files in the archive over the eCos
>>> repository.
>>>
>>> http://download.westlicht.ch/lwip-20090827.tar.gz
> Hi Simon,
> 
> I tried building a new linux synth target with the lwip_sequential package
> selected (using the ecos supplied i386-elf GCC).

You should probably try with the lasted i386-elf toolchain from 
eCosCentric, at least that's what I'm using for my tests here.

> 
> I ran into some errors when I try ti build the target.
> 
> First there was a missing bracket in
> packages/net/lwip_tcpip/current/src/core/ipv4/ip.c
> Line 413.

That should not happen!

> After fixing that, I get a bunch of errors:
> 
> Wall -Wpointer-arith -Wstrict-prototypes -Wundef  -Wno-write-strings
> -g -O2 -ffunction-sections -fdata-sections  -fno-exceptions
> -fno-stack-protector -Wp,-MD,src/api/tcpip.tmp -o
> src/api/net_lwip_tcpip_tcpip.o
> ...
> ...
> /home/mandeep/ecos/ecos-3.0/packages/net/lwip_tcpip/current/src/ecos/sio.c:169:
> error: expected ‘;’ before ‘info’
> /home/mandeep/ecos/ecos-3.0/packages/net/lwip_tcpip/current/src/ecos/sio.c:177:
> error: ‘info’ undeclared (first use in this function)
> make[1]: *** [src/ecos/sio.o.d] Error 1
> make[1]: *** Waiting for unfinished jobs....
> make[1]: Leaving directory
> `/home/mandeep/ecos/lwip-131/lwip-131_build/net/lwip_tcpip/current'
> make: *** [build] Error 2
> make: Leaving directory `/home/mandeep/ecos/lwip-131/lwip-131_build'
> 
> I'm sure this port compiles fine but somehow my build seems to be
> missing something. I've checked and I have
> the serialio.h file

Well there was actually a mistake. I did compile sio.c even when serial 
support is not needed (no SLIP or PPP). The warnings in socket.h should 
not matter, but I'll look into them.

> $ find packages/ -name serialio.h
> packages/io/serial/v3_0/include/serialio.h

Headers in the eCos repository will not be found when compiling, only 
the headers which are copied over to your build tree are recognized.

Well I fixed the bug with sio.c

Here is the fixed release: 
http://download.westlicht.ch/lwip-20090827-1.tar.gz

Copy all the archives files over the existing files in your eCos 
repository. Then use the following to build:

 > mkdir testbuild
 > cd testbuild
 > ecosconfig new linux lwip_eth_sequential

Note: If you want to build with i386-elf toolchain you need to edit 
ecos.ecc and change the user_value for CYGBLD_GLOBAL_COMMAND_PREFIX from 
"" to "i386-elf"

 > ecosconfig tree
 > make
 > make -C net/lwip_tcpip/current tests

If this does not compile without errors there is something wrong with 
your setup. What is your environment?

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Mandeep Sandhu]

>
> Well there was actually a mistake. I did compile sio.c even when serial
> support is not needed (no SLIP or PPP). The warnings in socket.h should not
> matter, but I'll look into them.
>
>> $ find packages/ -name serialio.h
>> packages/io/serial/v3_0/include/serialio.h
>
> Headers in the eCos repository will not be found when compiling, only the
> headers which are copied over to your build tree are recognized.
>
> Well I fixed the bug with sio.c
>
> Here is the fixed release:
> http://download.westlicht.ch/lwip-20090827-1.tar.gz

Thanks!

>
> Copy all the archives files over the existing files in your eCos repository.
> Then use the following to build:
>
>> mkdir testbuild
>> cd testbuild
>> ecosconfig new linux lwip_eth_sequential
>
> Note: If you want to build with i386-elf toolchain you need to edit ecos.ecc
> and change the user_value for CYGBLD_GLOBAL_COMMAND_PREFIX from "" to
> "i386-elf"

Yup. I'm doing that already.
>
>> ecosconfig tree
>> make
>> make -C net/lwip_tcpip/current tests
>
> If this does not compile without errors there is something wrong with your
> setup. What is your environment?

I'm running Ubuntu 9.04. Using the i386 toolchain that comes with ecos-3.0

Regards,
-mandeep

>
> Simon
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Mandeep Sandhu]

On Thu, Aug 27, 2009 at 7:21 PM, Mandeep
Sandhu<mandeepsandhu.chd@gmail.com> wrote:
>>
>> Well there was actually a mistake. I did compile sio.c even when serial
>> support is not needed (no SLIP or PPP). The warnings in socket.h should not
>> matter, but I'll look into them.
>>
>>> $ find packages/ -name serialio.h
>>> packages/io/serial/v3_0/include/serialio.h
>>
>> Headers in the eCos repository will not be found when compiling, only the
>> headers which are copied over to your build tree are recognized.
>>
>> Well I fixed the bug with sio.c
>>
>> Here is the fixed release:
>> http://download.westlicht.ch/lwip-20090827-1.tar.gz

This one compiled all the way through (leaving a few "warnings")!!

Thanks,
-mandeep

>
> Thanks!
>
>>
>> Copy all the archives files over the existing files in your eCos repository.
>> Then use the following to build:
>>
>>> mkdir testbuild
>>> cd testbuild
>>> ecosconfig new linux lwip_eth_sequential
>>
>> Note: If you want to build with i386-elf toolchain you need to edit ecos.ecc
>> and change the user_value for CYGBLD_GLOBAL_COMMAND_PREFIX from "" to
>> "i386-elf"
>
> Yup. I'm doing that already.
>>
>>> ecosconfig tree
>>> make
>>> make -C net/lwip_tcpip/current tests
>>
>> If this does not compile without errors there is something wrong with your
>> setup. What is your environment?
>
> I'm running Ubuntu 9.04. Using the i386 toolchain that comes with ecos-3.0
>
> Regards,
> -mandeep
>
>>
>> Simon
>>
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Simon Kallweit]

Mandeep Sandhu wrote:
> On Thu, Aug 27, 2009 at 7:21 PM, Mandeep
> Sandhu<mandeepsandhu.chd@gmail.com> wrote:
>>> Well there was actually a mistake. I did compile sio.c even when serial
>>> support is not needed (no SLIP or PPP). The warnings in socket.h should not
>>> matter, but I'll look into them.
>>>
>>>> $ find packages/ -name serialio.h
>>>> packages/io/serial/v3_0/include/serialio.h
>>> Headers in the eCos repository will not be found when compiling, only the
>>> headers which are copied over to your build tree are recognized.
>>>
>>> Well I fixed the bug with sio.c
>>>
>>> Here is the fixed release:
>>> http://download.westlicht.ch/lwip-20090827-1.tar.gz
> 
> This one compiled all the way through (leaving a few "warnings")!!

Good news! I'll look into these warnings in socket.c when I get some time.

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Sergei Gavrikov]

On Thu, Aug 27, 2009 at 04:10:52PM +0200, Simon Kallweit wrote:
> Mandeep Sandhu wrote:
>> On Thu, Aug 27, 2009 at 7:21 PM, Mandeep
>> Sandhu<mandeepsandhu.chd@gmail.com> wrote:
>>>> Well there was actually a mistake. I did compile sio.c even when serial
>>>> support is not needed (no SLIP or PPP). The warnings in socket.h should not
>>>> matter, but I'll look into them.
>>>>
>>>>> $ find packages/ -name serialio.h
>>>>> packages/io/serial/v3_0/include/serialio.h
>>>> Headers in the eCos repository will not be found when compiling, only the
>>>> headers which are copied over to your build tree are recognized.
>>>>
>>>> Well I fixed the bug with sio.c
>>>>
>>>> Here is the fixed release:
>>>> http://download.westlicht.ch/lwip-20090827-1.tar.gz
>>
>> This one compiled all the way through (leaving a few "warnings")!!
>
> Good news! I'll look into these warnings in socket.c when I get some time.

Simon, all warning will go away if you enter CDL for LWIP_ERR_T, look,
please, at lwip/err.h. By default that is signed char (?!), so its
capacity is quite overflowed. I just tried an ugly addition in err.h

#define LWIP_ERR_T unsigned int

and that fixed all gcc complains in socket.c. I checked it, i.e. with that tweak
all package is compiled silently (arm-elf-gcc 4.3.2), just alone warning:

sequential.c:113: warning: ‘set_ip_addr’ defined but not used

Sergei

>
> Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Sergei Gavrikov]

On Thu, Aug 27, 2009 at 05:47:37PM +0300, Sergei Gavrikov wrote:
> On Thu, Aug 27, 2009 at 04:10:52PM +0200, Simon Kallweit wrote:
> > Mandeep Sandhu wrote:
> >> On Thu, Aug 27, 2009 at 7:21 PM, Mandeep
> >> Sandhu<mandeepsandhu.chd@gmail.com> wrote:
> >>>> Well there was actually a mistake. I did compile sio.c even when serial
> >>>> support is not needed (no SLIP or PPP). The warnings in socket.h should not
> >>>> matter, but I'll look into them.
> >>>>
> >>>>> $ find packages/ -name serialio.h
> >>>>> packages/io/serial/v3_0/include/serialio.h
> >>>> Headers in the eCos repository will not be found when compiling, only the
> >>>> headers which are copied over to your build tree are recognized.
> >>>>
> >>>> Well I fixed the bug with sio.c
> >>>>
> >>>> Here is the fixed release:
> >>>> http://download.westlicht.ch/lwip-20090827-1.tar.gz
> >>
> >> This one compiled all the way through (leaving a few "warnings")!!
> >
> > Good news! I'll look into these warnings in socket.c when I get some time.
> 
> Simon, all warning will go away if you enter CDL for LWIP_ERR_T, look,
> please, at lwip/err.h. By default that is signed char (?!), so its
> capacity is quite overflowed. I just tried an ugly addition in err.h
> 
> #define LWIP_ERR_T unsigned int
                     ^^^^^^^^^^^^

Ups, It seems that shoult be 'int', the results are the same (no warns).

Sergei

> 
> and that fixed all gcc complains in socket.c. I checked it, i.e. with that tweak
> all package is compiled silently (arm-elf-gcc 4.3.2), just alone warning:
> 
> sequential.c:113: warning: ‘set_ip_addr’ defined but not used
> 
> Sergei
> 
> >
> > Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Mandeep Sandhu]

>>>>
>>>> Well I fixed the bug with sio.c
>>>>
>>>> Here is the fixed release:
>>>> http://download.westlicht.ch/lwip-20090827-1.tar.gz
>>
>> This one compiled all the way through (leaving a few "warnings")!!
>
> Good news! I'll look into these warnings in socket.c when I get some time.

Hi Simon,

I'm trying to use your new 1.3.1 stack with my app. The app currently works fine
with the current version lwIP (1.1.1). I'm using the Linux synthetic
target with a
static IP configured to eth0.

I'm currently stuck at getting the netif struct corresponding to my
only ethernet
interface eth0. It is unable to find my interface!

I'm passing the name as "et0". This was working fine with the previous version
of lwIP.

I've enabled the following options in my config:

* Netif support
* eth0 configuration -> Use DHCP is DISABLED.
  (static IP is configured)

Under I/O subsystems the following is enabled:
* Support for lwIP network stack
* Synthetic target ethernet driver -> Provide eth0 device

Is there any other option that I need to enable? I see that a lot of
configuration
options in the new version of the stack have changed so I might've missed out
some imp ones.

Also, I traced the lwIP init path (from lwIP_init()) and I didn't see any calls
to init_hw_drivers(). How are h/w drivers initialized then? Is there a different
mechanism now?

Thanks,
-mandeep


>
> Simon
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Simon Kallweit]

Mandeep Sandhu wrote:
>>>>> Well I fixed the bug with sio.c
>>>>>
>>>>> Here is the fixed release:
>>>>> http://download.westlicht.ch/lwip-20090827-1.tar.gz
>>> This one compiled all the way through (leaving a few "warnings")!!
>> Good news! I'll look into these warnings in socket.c when I get some time.
> 
> Hi Simon,
> 
> I'm trying to use your new 1.3.1 stack with my app. The app currently works fine
> with the current version lwIP (1.1.1). I'm using the Linux synthetic
> target with a
> static IP configured to eth0.
> 
> I'm currently stuck at getting the netif struct corresponding to my
> only ethernet
> interface eth0. It is unable to find my interface!
> 
> I'm passing the name as "et0". This was working fine with the previous version
> of lwIP.

Yes I think et0 should be the correct name.

> I've enabled the following options in my config:
> 
> * Netif support
> * eth0 configuration -> Use DHCP is DISABLED.
>   (static IP is configured)
> 
> Under I/O subsystems the following is enabled:
> * Support for lwIP network stack
> * Synthetic target ethernet driver -> Provide eth0 device
> 
> Is there any other option that I need to enable? I see that a lot of
> configuration
> options in the new version of the stack have changed so I might've missed out
> some imp ones.

This looks fine so far. I have not used the netif API myself, so I don't 
know if there were changes between the old and the new version. But I 
bet there are, as there was lots of work between 1.1.1 and 1.3.1.

Can you please show us the code you are trying to use with the netif 
API? Maybe we should also add a netif API test to the lwip package.

> Also, I traced the lwIP init path (from lwIP_init()) and I didn't see any calls
> to init_hw_drivers(). How are h/w drivers initialized then? Is there a different
> mechanism now?

Well the drivers are initialized in cyg_lwip_simple_init() in 
ecos/simple.c (for simple mode) and tcpip_init_done() in 
ecos/sequential.c (for sequential mode) with the following code:

         // Initialize network devices
         for (t = &__NETDEVTAB__[0]; t != &__NETDEVTAB_END__; t++) {
             if (t->init(t)) {
                 t->status = CYG_NETDEVTAB_STATUS_AVAIL;
             } else {
                 // Device not [currently] available
                 t->status = 0;
             }
         }


Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Mandeep Sandhu]

On Tue, Sep 1, 2009 at 5:50 PM, Simon Kallweit<simon.kallweit@intefo.ch> wrote:
> Mandeep Sandhu wrote:
>>>>>>
>
> This looks fine so far. I have not used the netif API myself, so I don't
> know if there were changes between the old and the new version. But I bet
> there are, as there was lots of work between 1.1.1 and 1.3.1.

I'm not particularly inclined to using the netif API.

If I can get the IP address of my interface "et0" by any other means then thats
fine too, as I'm only using it to retrieve the static IP assigned to
my interface.

Is there any other way achieve this?

>
> Can you please show us the code you are trying to use with the netif API?
> Maybe we should also add a netif API test to the lwip package.

Sure. It's simply a call to netif_find().

<snip>
struct netif *local = NULL;
local = netif_find("et0");
...
</snip>

I'm getting "local" as NULL. Also enabling netif debugs show this:

netif_find: didn't find et

Also, I forgot to mention that I'm using the sequential API.

>
>> Also, I traced the lwIP init path (from lwIP_init()) and I didn't see any
>> calls
>> to init_hw_drivers(). How are h/w drivers initialized then? Is there a
>> different
>> mechanism now?
>
> Well the drivers are initialized in cyg_lwip_simple_init() in ecos/simple.c
> (for simple mode) and tcpip_init_done() in ecos/sequential.c (for sequential
> mode) with the following code:
>
>        // Initialize network devices
>        for (t = &__NETDEVTAB__[0]; t != &__NETDEVTAB_END__; t++) {
>            if (t->init(t)) {
>                t->status = CYG_NETDEVTAB_STATUS_AVAIL;
>            } else {
>                // Device not [currently] available
>                t->status = 0;
>            }
>        }

Ok. Thanks. This is essentially the same stuff as was in  init_hw_drivers()! :)

Regards,
-mandeep

>
>
> Simon
>

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Simon Kallweit]

Mandeep Sandhu wrote:
> On Tue, Sep 1, 2009 at 5:50 PM, Simon Kallweit<simon.kallweit@intefo.ch> wrote:
>> Mandeep Sandhu wrote:
>> This looks fine so far. I have not used the netif API myself, so I don't
>> know if there were changes between the old and the new version. But I bet
>> there are, as there was lots of work between 1.1.1 and 1.3.1.
> 
> I'm not particularly inclined to using the netif API.
> 
> If I can get the IP address of my interface "et0" by any other means then thats
> fine too, as I'm only using it to retrieve the static IP assigned to
> my interface.
> 
> Is there any other way achieve this?
> 
>> Can you please show us the code you are trying to use with the netif API?
>> Maybe we should also add a netif API test to the lwip package.
> 
> Sure. It's simply a call to netif_find().
> 
> <snip>
> struct netif *local = NULL;
> local = netif_find("et0");
> ...
> </snip>
> 
> I'm getting "local" as NULL. Also enabling netif debugs show this:
> 
> netif_find: didn't find et

Well, I had a quick look at the source of netif_add() and netif_find() 
and I can't really see what could potentially go wrong here. Are you 
sure that your et0 netif is properly initialized? Did you start from the 
lwip_eth_sequential template?

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Mandeep Sandhu]

> Well, I had a quick look at the source of netif_add() and netif_find() and I
> can't really see what could potentially go wrong here. Are you sure that

I think netif_add is not being called at all during execution, because I don't
see any logs corresponding to that.

Also, I do all n/w operations _after_ doing lwip_init()

> your et0 netif is properly initialized? Did you start from the
> lwip_eth_sequential template?

Actually I had changed it from simple mode to sequential one.

I'll start afresh with sequential mode and see how it goes.

Thanks,
-mandeep

>
> Simon
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Simon Kallweit]

Mandeep Sandhu wrote:
>> Well, I had a quick look at the source of netif_add() and netif_find() and I
>> can't really see what could potentially go wrong here. Are you sure that
> 
> I think netif_add is not being called at all during execution, because I don't
> see any logs corresponding to that.

Well, I think if the synth eth driver is not initialized properly, the 
netif will not be added to the list.

But obviously it worked for lwip 1.1.1. Any ideas?

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Mandeep Sandhu]

On Tue, Sep 1, 2009 at 6:30 PM, Simon Kallweit<simon.kallweit@intefo.ch> wrote:
> Mandeep Sandhu wrote:
>>>
>>> Well, I had a quick look at the source of netif_add() and netif_find()
>>> and I
>>> can't really see what could potentially go wrong here. Are you sure that
>>
>> I think netif_add is not being called at all during execution, because I
>> don't
>> see any logs corresponding to that.
>
> Well, I think if the synth eth driver is not initialized properly, the netif
> will not be added to the list.
>
> But obviously it worked for lwip 1.1.1. Any ideas?

Well, something worked....and something crashed! :P

I replaced lwip_init() with cyg_lwip_sequential_init().

It's being used in all the test apps). The only difference is, the test apps
call cyg_lwip_thread_new() to create a new thread, while I call sys_thread_new()
(though this is internally calling cyg_lwip_thread_new())

With this I see the n/w interface being initialized, but the app crashes/hangs
after init-ing the interface:

...
netif_set_ipaddr: netif address being changed
netif: IP address of interface  set to 11.1.1.1
netif: netmask of interface  set to 255.255.255.0
netif: GW address of interface  set to 0.0.0.0
netif: added interface et IP addr 11.1.1.1 netmask 255.255.255.0 gw 0.0.0.0
netif: setting default interface et


After this nothing happens. I think the app's crashed here!

Any more idea's people?!

Thanks for your time.

Regards,
-mandeep


>
> Simon
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Simon Kallweit]

Mandeep Sandhu wrote:
> On Tue, Sep 1, 2009 at 6:30 PM, Simon Kallweit<simon.kallweit@intefo.ch> wrote:
>> Mandeep Sandhu wrote:
>>>> Well, I had a quick look at the source of netif_add() and netif_find()
>>>> and I
>>>> can't really see what could potentially go wrong here. Are you sure that
>>> I think netif_add is not being called at all during execution, because I
>>> don't
>>> see any logs corresponding to that.
>> Well, I think if the synth eth driver is not initialized properly, the netif
>> will not be added to the list.
>>
>> But obviously it worked for lwip 1.1.1. Any ideas?
> 
> Well, something worked....and something crashed! :P
> 
> I replaced lwip_init() with cyg_lwip_sequential_init().

You should not call lwip_init() when using the ecos lwip port. You need 
to use cyg_lwip_simple_init() or cyg_lwip_sequential_init(). Well, I 
really should add some documentation I guess.

> It's being used in all the test apps). The only difference is, the test apps
> call cyg_lwip_thread_new() to create a new thread, while I call sys_thread_new()
> (though this is internally calling cyg_lwip_thread_new())

sys_thread_new() will use preallocated memory for the stack, while 
cyg_lwip_thread_new() will take the stack as an argument. Therefore by 
default you should use cyg_lwip_thread_new(). When using 
sys_thread_new() the ecos should fail when all preallocated memory is used.

> With this I see the n/w interface being initialized, but the app crashes/hangs
> after init-ing the interface:
> 
> ...
> netif_set_ipaddr: netif address being changed
> netif: IP address of interface  set to 11.1.1.1
> netif: netmask of interface  set to 255.255.255.0
> netif: GW address of interface  set to 0.0.0.0
> netif: added interface et IP addr 11.1.1.1 netmask 255.255.255.0 gw 0.0.0.0
> netif: setting default interface et
> 
> 
> After this nothing happens. I think the app's crashed here!

What should happen next?

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Mandeep Sandhu]

On Tue, Sep 1, 2009 at 7:08 PM, Simon Kallweit<simon.kallweit@intefo.ch> wrote:
> Mandeep Sandhu wrote:
>>
> You should not call lwip_init() when using the ecos lwip port. You need to
> use cyg_lwip_simple_init() or cyg_lwip_sequential_init(). Well, I really
> should add some documentation I guess.

Yes. Documentation would help a lot. Thanks.
>
>> It's being used in all the test apps). The only difference is, the test
>> apps
>> call cyg_lwip_thread_new() to create a new thread, while I call
>> sys_thread_new()
>> (though this is internally calling cyg_lwip_thread_new())
>
> sys_thread_new() will use preallocated memory for the stack, while
> cyg_lwip_thread_new() will take the stack as an argument. Therefore by
> default you should use cyg_lwip_thread_new(). When using sys_thread_new()
> the ecos should fail when all preallocated memory is used.

But sys_thread_new() also takes stacksize as an argument. It passes
the same value
to cyg_lwip_thread_new() after validating it. So I guess it should be ok.

>
>> With this I see the n/w interface being initialized, but the app
>> crashes/hangs
>> after init-ing the interface:
>>
>> ...
>> netif_set_ipaddr: netif address being changed
>> netif: IP address of interface  set to 11.1.1.1
>> netif: netmask of interface  set to 255.255.255.0
>> netif: GW address of interface  set to 0.0.0.0
>> netif: added interface et IP addr 11.1.1.1 netmask 255.255.255.0 gw
>> 0.0.0.0
>> netif: setting default interface et

Whoops! Sorry. I guess its not obvious to others on what happens next! :)

Well, after this I should see debug o/p of my thread. Here's the code:
...
...
cyg_lwip_sequential_init();
sys_thread_new("My thread",
                   m_main,
                   (void *)"My thread",
                   0x1000,
                   5);
...
...

void
m_main( void *arg )
{
    LOG(LOG_DEBUG,"%s started...", (char *)arg);
...
...

So I'm expecting "My thread started" as the next o/p.

Same code works fine with 1.1.1

-mandeep
>>
>>
>> After this nothing happens. I think the app's crashed here!
>
> What should happen next?
>
> Simon
>

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Simon Kallweit]

Mandeep Sandhu wrote:
> On Tue, Sep 1, 2009 at 7:08 PM, Simon Kallweit<simon.kallweit@intefo.ch> wrote:
>> Mandeep Sandhu wrote:
>> sys_thread_new() will use preallocated memory for the stack, while
>> cyg_lwip_thread_new() will take the stack as an argument. Therefore by
>> default you should use cyg_lwip_thread_new(). When using sys_thread_new()
>> the ecos should fail when all preallocated memory is used.
> 
> But sys_thread_new() also takes stacksize as an argument. It passes
> the same value
> to cyg_lwip_thread_new() after validating it. So I guess it should be ok.

Yes, sys_thread_new() takes a stacksize argument, but no pointer to the 
actual memory. The current code uses a statically allocated buffer for 
all lwip's internal stacks, but it is not large enough to hold 
additional stacks from users, hence the cyg_lwip_thread_new() API where 
the user can provide a pointer to the actual stack memory to be used.

Your application should FAIL when using sys_thread_new() with the 
following message:

"Not enough memory to allocate the thread's stack. You may want to use 
cyg_lwip_thread_new() instead of sys_thread_new() so you can provide 
external stack memory."

This message should pop up unless you have asserts disabled?!?

Maybe I should add an option in the CDL to enlarge the statically 
allocated internal stack memory so users could allocate threads with 
sys_thread_new(). But I don't personally like it, as you may waste 
memory. cyg_lwip_thread_new() does solve this problem by forcing you to 
allocate the stack memory yourself.

Please try to use cyg_lwip_thread_new() and tell me if that works.

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Mandeep Sandhu]

On Tue, Sep 1, 2009 at 9:07 PM, Simon Kallweit<simon.kallweit@intefo.ch> wrote:
> Mandeep Sandhu wrote:
>>
>> On Tue, Sep 1, 2009 at 7:08 PM, Simon Kallweit<simon.kallweit@intefo.ch>
>> wrote:
>>>
>>> Mandeep Sandhu wrote:
>>> sys_thread_new() will use preallocated memory for the stack, while
>>> cyg_lwip_thread_new() will take the stack as an argument. Therefore by
>>> default you should use cyg_lwip_thread_new(). When using sys_thread_new()
>>> the ecos should fail when all preallocated memory is used.
>>
>> But sys_thread_new() also takes stacksize as an argument. It passes
>> the same value
>> to cyg_lwip_thread_new() after validating it. So I guess it should be ok.
>
> Yes, sys_thread_new() takes a stacksize argument, but no pointer to the
> actual memory. The current code uses a statically allocated buffer for all
> lwip's internal stacks, but it is not large enough to hold additional stacks
> from users, hence the cyg_lwip_thread_new() API where the user can provide a
> pointer to the actual stack memory to be used.
>
> Your application should FAIL when using sys_thread_new() with the following
> message:
>
> "Not enough memory to allocate the thread's stack. You may want to use
> cyg_lwip_thread_new() instead of sys_thread_new() so you can provide
> external stack memory."

I dont see this message.
>
> This message should pop up unless you have asserts disabled?!?

No. They're enabled.
>
> Maybe I should add an option in the CDL to enlarge the statically allocated
> internal stack memory so users could allocate threads with sys_thread_new().
> But I don't personally like it, as you may waste memory.
> cyg_lwip_thread_new() does solve this problem by forcing you to allocate the
> stack memory yourself.
>
> Please try to use cyg_lwip_thread_new() and tell me if that works.

I'll do that now. Thanks for tips.

Also I noted one more thing.

My thread which calls netif_find() is executed _BEFORE_ I see the netif_add()
messages!!!
Could this be a thread synchronization issue? Should I wait for the
netif init() to
complete?

Regards,
-mandeep

>
> Simon
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Simon Kallweit]

Mandeep Sandhu wrote:
> On Tue, Sep 1, 2009 at 9:07 PM, Simon Kallweit<simon.kallweit@intefo.ch> wrote:
>> Mandeep Sandhu wrote:
>> Please try to use cyg_lwip_thread_new() and tell me if that works.
> 
> I'll do that now. Thanks for tips.
> 
> Also I noted one more thing.
> 
> My thread which calls netif_find() is executed _BEFORE_ I see the netif_add()
> messages!!!
> Could this be a thread synchronization issue? Should I wait for the
> netif init() to
> complete?

You need to wait for cyg_lwip_sequential_init() to return before 
creating user threads.

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Mandeep Sandhu]

>
> You need to wait for cyg_lwip_sequential_init() to return before creating
> user threads.

That should be happening since I'm calling cyg_lwip_sequential_init() before
even creating my own thread!

<snip>

cyg_lwip_sequential_init();

cyg_lwip_thread_new( "My thread", m_main, (void *)"My thread",
my_stack, 0x1000, 5 );
...
...
<snip>

I'll enable more debugs to see where it's getting stuck.

>
> Simon
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Mandeep Sandhu]

On Wed, Sep 2, 2009 at 11:45 AM, Mandeep
Sandhu<mandeepsandhu.chd@gmail.com> wrote:
>>
>> You need to wait for cyg_lwip_sequential_init() to return before creating
>> user threads.
>
> That should be happening since I'm calling cyg_lwip_sequential_init() before
> even creating my own thread!
>
> <snip>
>
> cyg_lwip_sequential_init();
>
> cyg_lwip_thread_new( "My thread", m_main, (void *)"My thread",
> my_stack, 0x1000, 5 );
> ...
> ...
> <snip>
>
> I'll enable more debugs to see where it's getting stuck.

Hi Simon,

I think I've partially fixed the issue. While going through the default config
I noticed that the TCPIP thread's default priority is set to 8. Which was lower
than my threads prio - 5.

After changing it to 2, it's able to find the interface (et0) with all
the right settings.

Now another problem has cropped up! :) Sorry.

My app's actually a DHCP server. So it receives DHCP packets with 0.0.0.0
as the src IP. However, the stack is dropping them with the following message:

ip_input: iphdr->dest 0xffffffff netif->ip_addr 0x101010b (0xffffff,
0x1010b, 0xff000000)
ip_input: packet accepted on interface et
ip_input: packet source is not valid.

I've enabled the following in my config:

* Support broadcast filter
* Receive support

Is anything else needed?

Just one more thing:

While tracing the path from  cyg_lwip_sequential_init() to see what
all happens, I saw that
we end up calling lwip_init() twice!

Once in cyg_lwip_sequential_init() and then again in tcpip_init().

Why do we do it twice? The only function called between these 2 calls is
cyg_semaphore_init().

I think we can remove one of these. Or am I missing something?

Thanks,
-mandeep

>
>>
>> Simon
>>
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Simon Kallweit]

Mandeep Sandhu wrote:
> On Wed, Sep 2, 2009 at 11:45 AM, Mandeep
> Sandhu<mandeepsandhu.chd@gmail.com> wrote:
>>> You need to wait for cyg_lwip_sequential_init() to return before creating
>>> user threads.
>> That should be happening since I'm calling cyg_lwip_sequential_init() before
>> even creating my own thread!
>>
>> <snip>
>>
>> cyg_lwip_sequential_init();
>>
>> cyg_lwip_thread_new( "My thread", m_main, (void *)"My thread",
>> my_stack, 0x1000, 5 );
>> ...
>> ...
>> <snip>
>>
>> I'll enable more debugs to see where it's getting stuck.
> 
> Hi Simon,
> 
> I think I've partially fixed the issue. While going through the default config
> I noticed that the TCPIP thread's default priority is set to 8. Which was lower
> than my threads prio - 5.
> 
> After changing it to 2, it's able to find the interface (et0) with all
> the right settings.

Well, that does not really make sense. cyg_lwip_sequential_init() will 
not return until the lwip stack is initialized, and initializing 
ethernet device drivers is part of that. This *must* work even when the 
TCPIP thread has lower priority, as long as you start your application 
thread *after* the execution of cyg_lwip_sequential_init(). By starting 
*after* I mean that you also have to make sure that 
cyg_lwip_sequential_init() and starting your applications thread is done 
in the same thread!

I hope I didn't miss the obvious here, but that's how it should work.

> Now another problem has cropped up! :) Sorry.
> 
> My app's actually a DHCP server. So it receives DHCP packets with 0.0.0.0
> as the src IP. However, the stack is dropping them with the following message:
> 
> ip_input: iphdr->dest 0xffffffff netif->ip_addr 0x101010b (0xffffff,
> 0x1010b, 0xff000000)
> ip_input: packet accepted on interface et
> ip_input: packet source is not valid.
> 
> I've enabled the following in my config:
> 
> * Support broadcast filter
> * Receive support
> 
> Is anything else needed?

May I ask you to forward this question to the lwip mailing list, I have 
no experience on that subject myself.

> Just one more thing:
> 
> While tracing the path from  cyg_lwip_sequential_init() to see what
> all happens, I saw that
> we end up calling lwip_init() twice!
> 
> Once in cyg_lwip_sequential_init() and then again in tcpip_init().
> 
> Why do we do it twice? The only function called between these 2 calls is
> cyg_semaphore_init().
> 
> I think we can remove one of these. Or am I missing something?

Well, that's a bug. Thanks for spotting. I wrapped a new release you can 
download from:

http://download.westlicht.ch/lwip-20090902.tar.gz

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Mandeep Sandhu]

>>> <snip>
>>>
>>> cyg_lwip_sequential_init();
>>>
>>> cyg_lwip_thread_new( "My thread", m_main, (void *)"My thread",
>>> my_stack, 0x1000, 5 );
>>> ...
>>> ...
>>> <snip>
>>>
>>> I'll enable more debugs to see where it's getting stuck.
>>
>> After changing it to 2, it's able to find the interface (et0) with all
>> the right settings.
>
> Well, that does not really make sense. cyg_lwip_sequential_init() will not
> return until the lwip stack is initialized, and initializing ethernet device
> drivers is part of that. This *must* work even when the TCPIP thread has
> lower priority, as long as you start your application thread *after* the
> execution of cyg_lwip_sequential_init(). By starting *after* I mean that you
> also have to make sure that cyg_lwip_sequential_init() and starting your
> applications thread is done in the same thread!
>
> I hope I didn't miss the obvious here, but that's how it should work.

Well, I checked the code again. The netif init is done as part of
tcpip_init_done().
This I see is being called in tcpip_thread(). This function is being
executed in the
tcpip thread's context.

I guess this is why the priority of the threads matters.

Would do you think?

>
>> Now another problem has cropped up! :) Sorry.
>>
>> My app's actually a DHCP server. So it receives DHCP packets with 0.0.0.0
>> as the src IP. However, the stack is dropping them with the following
>> message:
>>
>> ip_input: iphdr->dest 0xffffffff netif->ip_addr 0x101010b (0xffffff,
>> 0x1010b, 0xff000000)
>> ip_input: packet accepted on interface et
>> ip_input: packet source is not valid.
>>
>> I've enabled the following in my config:
>>
>> * Support broadcast filter
>> * Receive support
>>
>> Is anything else needed?
>
> May I ask you to forward this question to the lwip mailing list, I have no
> experience on that subject myself.

Ok. I'll do that.

>
>> Just one more thing:
>>
>> While tracing the path from  cyg_lwip_sequential_init() to see what
>> all happens, I saw that
>> we end up calling lwip_init() twice!
>>
>> Once in cyg_lwip_sequential_init() and then again in tcpip_init().
>>
>> Why do we do it twice? The only function called between these 2 calls is
>> cyg_semaphore_init().
>>
>> I think we can remove one of these. Or am I missing something?
>
> Well, that's a bug. Thanks for spotting. I wrapped a new release you can
> download from:
>
> http://download.westlicht.ch/lwip-20090902.tar.gz

Thanks!

-mandeep

>
> Simon
>

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Simon Kallweit]

Mandeep Sandhu wrote:
>>>> <snip>
>>>>
>>>> cyg_lwip_sequential_init();
>>>>
>>>> cyg_lwip_thread_new( "My thread", m_main, (void *)"My thread",
>>>> my_stack, 0x1000, 5 );
>>>> ...
>>>> ...
>>>> <snip>
>>>>
>>>> I'll enable more debugs to see where it's getting stuck.
>>> After changing it to 2, it's able to find the interface (et0) with all
>>> the right settings.
>> Well, that does not really make sense. cyg_lwip_sequential_init() will not
>> return until the lwip stack is initialized, and initializing ethernet device
>> drivers is part of that. This *must* work even when the TCPIP thread has
>> lower priority, as long as you start your application thread *after* the
>> execution of cyg_lwip_sequential_init(). By starting *after* I mean that you
>> also have to make sure that cyg_lwip_sequential_init() and starting your
>> applications thread is done in the same thread!
>>
>> I hope I didn't miss the obvious here, but that's how it should work.
> 
> Well, I checked the code again. The netif init is done as part of
> tcpip_init_done().
> This I see is being called in tcpip_thread(). This function is being
> executed in the
> tcpip thread's context.
> 
> I guess this is why the priority of the threads matters.
> 
> Would do you think?

There is a semaphore created in cyg_lwip_sequential_init() which will 
block until all initialization (including ethernet devices) in the tcpip 
thread is done. Therefore it's priority does not matter. 
cyg_lwip_sequential_init() should not return before initialization is 
completed.

I just reviewed the code and found that the semaphore is initialized 
with 1, which is clearly a bug, it should be initialized with 0 so that 
the following call to cyg_semaphore_wait() is actually blocking the 
thread until initialization is done.

My mistake, sorry! Hope it works as intended now. New release:

http://download.westlicht.ch/lwip-20090903.tar.gz

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Mandeep Sandhu]

On Thu, Sep 3, 2009 at 2:22 PM, Simon Kallweit<simon.kallweit@intefo.ch> wrote:
> Mandeep Sandhu wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>> cyg_lwip_sequential_init();
>>>>>
>>>>> cyg_lwip_thread_new( "My thread", m_main, (void *)"My thread",
>>>>> my_stack, 0x1000, 5 );
>>>>> ...
>>>>> ...
>>>>> <snip>
>>>>>
>>>>> I'll enable more debugs to see where it's getting stuck.
>>>>
>>>> After changing it to 2, it's able to find the interface (et0) with all
>>>> the right settings.
>>>
>>> Well, that does not really make sense. cyg_lwip_sequential_init() will
>>> not
>>> return until the lwip stack is initialized, and initializing ethernet
>>> device
>>> drivers is part of that. This *must* work even when the TCPIP thread has
>>> lower priority, as long as you start your application thread *after* the
>>> execution of cyg_lwip_sequential_init(). By starting *after* I mean that
>>> you
>>> also have to make sure that cyg_lwip_sequential_init() and starting your
>>> applications thread is done in the same thread!
>>>
>>> I hope I didn't miss the obvious here, but that's how it should work.
>>
>> Well, I checked the code again. The netif init is done as part of
>> tcpip_init_done().
>> This I see is being called in tcpip_thread(). This function is being
>> executed in the
>> tcpip thread's context.
>>
>> I guess this is why the priority of the threads matters.
>>
>> Would do you think?
>
> There is a semaphore created in cyg_lwip_sequential_init() which will block
> until all initialization (including ethernet devices) in the tcpip thread is
> done. Therefore it's priority does not matter. cyg_lwip_sequential_init()
> should not return before initialization is completed.
>
> I just reviewed the code and found that the semaphore is initialized with 1,
> which is clearly a bug, it should be initialized with 0 so that the
> following call to cyg_semaphore_wait() is actually blocking the thread until
> initialization is done.
>
> My mistake, sorry! Hope it works as intended now. New release:
>
> http://download.westlicht.ch/lwip-20090903.tar.gz

Thanks Simon. I totally missed the sem init part...i guess since the sem is
init to 1...the thread never actually waits...and thats why I was seeing the
problem.

I'll try out the new build and let you know...

Thanks,
-mandeep

>
> Simon
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Simon Kallweit]

Mandeep Sandhu wrote:
> On Thu, Sep 3, 2009 at 2:22 PM, Simon Kallweit<simon.kallweit@intefo.ch> wrote:
>> Mandeep Sandhu wrote:
>> There is a semaphore created in cyg_lwip_sequential_init() which will block
>> until all initialization (including ethernet devices) in the tcpip thread is
>> done. Therefore it's priority does not matter. cyg_lwip_sequential_init()
>> should not return before initialization is completed.
>>
>> I just reviewed the code and found that the semaphore is initialized with 1,
>> which is clearly a bug, it should be initialized with 0 so that the
>> following call to cyg_semaphore_wait() is actually blocking the thread until
>> initialization is done.
>>
>> My mistake, sorry! Hope it works as intended now. New release:
>>
>> http://download.westlicht.ch/lwip-20090903.tar.gz
> 
> Thanks Simon. I totally missed the sem init part...i guess since the sem is
> init to 1...the thread never actually waits...and thats why I was seeing the
> problem.

Exactly. I glanced over this code more than once and it didn't occur to 
me. Thanks a lot for testing! This is really helpful.

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Mandeep Sandhu]

On Thu, Sep 3, 2009 at 2:34 PM, Simon Kallweit<simon.kallweit@intefo.ch> wrote:
> Mandeep Sandhu wrote:
>>
>> On Thu, Sep 3, 2009 at 2:22 PM, Simon Kallweit<simon.kallweit@intefo.ch>
>> wrote:
>>>
>>> Mandeep Sandhu wrote:
>>> There is a semaphore created in cyg_lwip_sequential_init() which will
>>> block
>>> until all initialization (including ethernet devices) in the tcpip thread
>>> is
>>> done. Therefore it's priority does not matter. cyg_lwip_sequential_init()
>>> should not return before initialization is completed.
>>>
>>> I just reviewed the code and found that the semaphore is initialized with
>>> 1,
>>> which is clearly a bug, it should be initialized with 0 so that the
>>> following call to cyg_semaphore_wait() is actually blocking the thread
>>> until
>>> initialization is done.
>>>
>>> My mistake, sorry! Hope it works as intended now. New release:
>>>
>>> http://download.westlicht.ch/lwip-20090903.tar.gz
>>
>> Thanks Simon. I totally missed the sem init part...i guess since the sem
>> is
>> init to 1...the thread never actually waits...and thats why I was seeing
>> the
>> problem.
>
> Exactly. I glanced over this code more than once and it didn't occur to me.
> Thanks a lot for testing! This is really helpful.

No problem. I'm just glad I'm able to help.

I downloaded your new rel. It still had that sem init'ed to 1! That should be
0 right? If thats the only change I'll do it in my local copy and test it.

-mandeep

>
> Simon
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Simon Kallweit]

Mandeep Sandhu wrote:
> On Thu, Sep 3, 2009 at 2:34 PM, Simon Kallweit<simon.kallweit@intefo.ch> wrote:
>> Mandeep Sandhu wrote:
>>> On Thu, Sep 3, 2009 at 2:22 PM, Simon Kallweit<simon.kallweit@intefo.ch>
>>> wrote:
>>>> Mandeep Sandhu wrote:
>>>> There is a semaphore created in cyg_lwip_sequential_init() which will
>>>> block
>>>> until all initialization (including ethernet devices) in the tcpip thread
>>>> is
>>>> done. Therefore it's priority does not matter. cyg_lwip_sequential_init()
>>>> should not return before initialization is completed.
>>>>
>>>> I just reviewed the code and found that the semaphore is initialized with
>>>> 1,
>>>> which is clearly a bug, it should be initialized with 0 so that the
>>>> following call to cyg_semaphore_wait() is actually blocking the thread
>>>> until
>>>> initialization is done.
>>>>
>>>> My mistake, sorry! Hope it works as intended now. New release:
>>>>
>>>> http://download.westlicht.ch/lwip-20090903.tar.gz
>>> Thanks Simon. I totally missed the sem init part...i guess since the sem
>>> is
>>> init to 1...the thread never actually waits...and thats why I was seeing
>>> the
>>> problem.
>> Exactly. I glanced over this code more than once and it didn't occur to me.
>> Thanks a lot for testing! This is really helpful.
> 
> No problem. I'm just glad I'm able to help.
> 
> I downloaded your new rel. It still had that sem init'ed to 1! That should be
> 0 right? If thats the only change I'll do it in my local copy and test it.

Oh my, git tricked me :) Yeah, this should be 0. Please see if that 
works. It did for me, before git tricked me, hehe

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Mandeep Sandhu]

On Thu, Sep 3, 2009 at 2:49 PM, Simon Kallweit<simon.kallweit@intefo.ch> wrote:
> Mandeep Sandhu wrote:
>>
>> On Thu, Sep 3, 2009 at 2:34 PM, Simon Kallweit<simon.kallweit@intefo.ch>
>> wrote:
>>>
>>> Mandeep Sandhu wrote:
>>>>
>>>> On Thu, Sep 3, 2009 at 2:22 PM, Simon Kallweit<simon.kallweit@intefo.ch>
>>>> wrote:
>>>>>
>>>>> Mandeep Sandhu wrote:
>>>>> There is a semaphore created in cyg_lwip_sequential_init() which will
>>>>> block
>>>>> until all initialization (including ethernet devices) in the tcpip
>>>>> thread
>>>>> is
>>>>> done. Therefore it's priority does not matter.
>>>>> cyg_lwip_sequential_init()
>>>>> should not return before initialization is completed.
>>>>>
>>>>> I just reviewed the code and found that the semaphore is initialized
>>>>> with
>>>>> 1,
>>>>> which is clearly a bug, it should be initialized with 0 so that the
>>>>> following call to cyg_semaphore_wait() is actually blocking the thread
>>>>> until
>>>>> initialization is done.
>>>>>
>>>>> My mistake, sorry! Hope it works as intended now. New release:
>>>>>
>>>>> http://download.westlicht.ch/lwip-20090903.tar.gz
>>>>
>>>> Thanks Simon. I totally missed the sem init part...i guess since the sem
>>>> is
>>>> init to 1...the thread never actually waits...and thats why I was seeing
>>>> the
>>>> problem.
>>>
>>> Exactly. I glanced over this code more than once and it didn't occur to
>>> me.
>>> Thanks a lot for testing! This is really helpful.
>>
>> No problem. I'm just glad I'm able to help.
>>
>> I downloaded your new rel. It still had that sem init'ed to 1! That should
>> be
>> 0 right? If thats the only change I'll do it in my local copy and test it.
>
> Oh my, git tricked me :) Yeah, this should be 0. Please see if that works.
> It did for me, before git tricked me, hehe

Yup. It worked! Thanks Simon.

Regards,
-mandeep

>
> Simon
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Sergei Gavrikov]

Mandeep Sandhu wrote:
> Simon Kallweit wrote:
> > Oh my, git tricked me :) Yeah, this should be 0. Please see if
> > that works.  It did for me, before git tricked me, hehe
> 
> Yup. It worked! Thanks Simon.

Hi Simon,

Is your lwip-1.3.1 development tree available from Internet? Is it
possible to clone it?

Thanks, regards,

Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Sergei Gavrikov]

On Thu, Aug 27, 2009 at 03:47:04PM +0200, Simon Kallweit wrote:
> Mandeep Sandhu wrote:
> Well I fixed the bug with sio.c
>
> Here is the fixed release:  
> http://download.westlicht.ch/lwip-20090827-1.tar.gz

Hi Simon,

Great! FYI. I tested your SLIP code on my ARM7 (LE) board. The score for
SLIP is (3 success from 3 tried):

+ http_sequential
+ tcpecho
+ udpecho

As you can see I have not issue with "udpecho" on slip interface as I
had on eth.

Regards,

Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Simon Kallweit]

Sergei Gavrikov wrote:
> On Thu, Aug 27, 2009 at 03:47:04PM +0200, Simon Kallweit wrote:
>> Mandeep Sandhu wrote:
>> Well I fixed the bug with sio.c
>>
>> Here is the fixed release:  
>> http://download.westlicht.ch/lwip-20090827-1.tar.gz
> 
> Hi Simon,
> 
> Great! FYI. I tested your SLIP code on my ARM7 (LE) board. The score for
> SLIP is (3 success from 3 tried):
> 
> + http_sequential
> + tcpecho
> + udpecho
> 
> As you can see I have not issue with "udpecho" on slip interface as I
> had on eth.

Now that's good news :) Thanks a lot for testing!

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Bart Veer]

>>>>> "Simon" == Simon Kallweit <simon.kallweit@intefo.ch> writes:

    >> I tried building a new linux synth target with the
    >> lwip_sequential package selected (using the ecos supplied
    >> i386-elf GCC).

    Simon> You should probably try with the lasted i386-elf toolchain
    Simon> from eCosCentric, at least that's what I'm using for my
    Simon> tests here.

Just FYI, plain gcc should now work with the latest synthetic target
code in anoncvs. I believe I have fixed the -fstack-protector issue
that caused problems for Ubuntu users, as well as the gdb internal
error that was reported for some executables.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Sergei Gavrikov]

On Thu, Aug 27, 2009 at 03:42:38PM +0100, Bart Veer wrote:
> >>>>> "Simon" == Simon Kallweit <simon.kallweit@intefo.ch> writes:
> 
>     >> I tried building a new linux synth target with the
>     >> lwip_sequential package selected (using the ecos supplied
>     >> i386-elf GCC).
> 
>     Simon> You should probably try with the lasted i386-elf toolchain
>     Simon> from eCosCentric, at least that's what I'm using for my
>     Simon> tests here.
> 
> Just FYI, plain gcc should now work with the latest synthetic target
> code in anoncvs. I believe I have fixed the -fstack-protector issue
> that caused problems for Ubuntu users, as well as the gdb internal
> error that was reported for some executables.

I confirm this, I use latest CVS, Ubuntu 8.04.3 LTS and I tested lwip
1.3.1 on synthetic target built the stuff using host's GCC(thank you
Bart).

Sergei

> 
> Bart
> 
> -- 
> Bart Veer                                   eCos Configuration Architect
> eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
> Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
> Registered in England and Wales: Reg No 4422071.
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Sergei Gavrikov]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

On Thu, Aug 27, 2009 at 06:49:59PM +0530, Mandeep Sandhu wrote:
> >> 1.3.1 for eCos. Just copy all the files in the archive over the eCos
> >> repository.
> >>
> >> http://download.westlicht.ch/lwip-20090827.tar.gz
> Hi Simon,
> 
> I tried building a new linux synth target with the lwip_sequential package
> selected (using the ecos supplied i386-elf GCC).
> 
> I ran into some errors when I try ti build the target.

Hi

Beeing in testinf Simon's SLIP addons I noticed that. That happenes
because sio.c, slipif.c are compiled by default. I move those sources in
CDL slip section and it seems compile passes okay. See the attachment, I
think that Simon will quick fix this compile issue and may be more
elegant than me.

> First there was a missing bracket in
> packages/net/lwip_tcpip/current/src/core/ipv4/ip.c
> Line 413.

Hm. I dint't turn IGMP and perhaps, I missed it.

> After fixing that, I get a bunch of errors:
 
[snip]

Warnings exist. Error should go away with proposal the above.

Sergei


[-- Attachment #2: lwip_net.cdl.patch --]
[-- Type: text/x-diff, Size: 1040 bytes --]

diff -r 3d77ea1625ff net/lwip_tcpip/current/cdl/lwip_net.cdl
--- a/net/lwip_tcpip/current/cdl/lwip_net.cdl	Thu Aug 27 12:54:28 2009 +0300
+++ b/net/lwip_tcpip/current/cdl/lwip_net.cdl	Thu Aug 27 16:42:43 2009 +0300
@@ -81,11 +81,9 @@
                     ecos/ppp.c                  \
                     ecos/sequential.c           \
                     ecos/simple.c               \
-                    ecos/sio.c                  \
                     ecos/sys_arch.c             \
                     netif/etharp.c              \
-                    netif/loopif.c              \
-                    netif/slipif.c
+                    netif/loopif.c
 
     cdl_option CYGIMP_LWIP_MODE {
         display         "Operation mode"
@@ -994,6 +992,9 @@
             default_value   0
             description     "
                 Support SLIP functionality."
+
+            compile ecos/slip.c  netif/slipif.c
+
                 
             cdl_option CYGDAT_LWIP_SLIPIF_DEV {
                 display         "Serial device"


[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Mandeep Sandhu]

>
> Hi
>
> Beeing in testinf Simon's SLIP addons I noticed that. That happenes
> because sio.c, slipif.c are compiled by default. I move those sources in
> CDL slip section and it seems compile passes okay. See the attachment, I
> think that Simon will quick fix this compile issue and may be more
> elegant than me.
>
>> First there was a missing bracket in
>> packages/net/lwip_tcpip/current/src/core/ipv4/ip.c
>> Line 413.
>
> Hm. I dint't turn IGMP and perhaps, I missed it.
>
>> After fixing that, I get a bunch of errors:
>
> [snip]
>
> Warnings exist. Error should go away with proposal the above.

Thanks Sergei. I'll try Simons new build and see if it helps.

Regards,
-mandeep

>
> Sergei
>
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Simon Kallweit]

Sergei Gavrikov wrote:
> On Thu, Aug 27, 2009 at 06:49:59PM +0530, Mandeep Sandhu wrote:
>>>> 1.3.1 for eCos. Just copy all the files in the archive over the eCos
>>>> repository.
>>>>
>>>> http://download.westlicht.ch/lwip-20090827.tar.gz
>> Hi Simon,
>>
>> I tried building a new linux synth target with the lwip_sequential package
>> selected (using the ecos supplied i386-elf GCC).
>>
>> I ran into some errors when I try ti build the target.
> 
> Hi
> 
> Beeing in testinf Simon's SLIP addons I noticed that. That happenes
> because sio.c, slipif.c are compiled by default. I move those sources in
> CDL slip section and it seems compile passes okay. See the attachment, I
> think that Simon will quick fix this compile issue and may be more
> elegant than me.

I already fixed it in the new release. I only added conditional 
compilation in sio.c as it is depended on by both SLIP and PPP. I did 
not move slipif.c as there is already a big #ifdef preventing a 
compilation if SLIP is not selected in the lwip opts. Should all be OK now.

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[agfa prayoga s]

Hi Simon,

okay,,, maybe i will try your patch for lwIP 1.3.0 first,,,

thanks

--
Agfa

--- On Thu, 8/27/09, Simon Kallweit <simon.kallweit@intefo.ch> wrote:

From: Simon Kallweit <simon.kallweit@intefo.ch>
Subject: Re: [ECOS] ecos + lwip
To: "agfa prayoga s" <fillariabrancoftii@yahoo.com>
Cc: "Sergei Gavrikov" <sergei.gavrikov@gmail.com>, "Mandeep Sandhu" <mandeepsandhu.chd@gmail.com>, "ecos-discuss" <ecos-discuss@ecos.sourceware.org>
Date: Thursday, August 27, 2009, 7:16 AM

agfa prayoga s wrote:
> Hi all,,,
> 
> did lwIP 1.3.0 port that Simon's patched for eCos 3.0 has improvement in
> memory footprint?
> 
> i am trying to run httpd example under lwip package on AT91SAM7X-EK board
> filled with AT91SAM7X256. that microcontroller only have 256KB ROM and
> 64KB RAM.
> 
> i have compiled the example successfully only with PBUF value 10, disable DHCP,
> SLIP, PPP, raw socket support, IP forwarding.
> 
> using arm-eabi-size, httpd binary has size:
> .text : 82740
> .data: 5428
> .bss: 50792
> 
> notice that the sum of .data and .bss is almost 56KB, near 64KB.
> 
> if i increase the PBUF value over 10(default value is 60), compilation process will failed with error that
> is no longer room in .bss because the limitation in 64KB.
> 
> maybe this is out of topic, but i appreciate your assistance...

Well that's hard to say. You would need to ask that question on the lwip list. I don't know if there are major differences in memory consumption between lwip 1.1.0 and 1.3.1. One advantage of my port is that it can be run in a completely polled mode (I call it simple mode), so you can run all your network code in a single thread, instead of multiple threads (at least 3). The old port did not directly offer that option. This can spare you quite a bit of memory (stacks). Notice that when using the simple mode, you will have to use the raw APIs (see httpd_simple example) and cannot use the netconn and socket APIs. In my project, I use the polled mode for the exact same reason (memory) with good results.

Simon

-- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss




      

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Simon Kallweit]

agfa prayoga s wrote:
> Hi all,,,
> 
> did lwIP 1.3.0 port that Simon's patched for eCos 3.0 has improvement in
> memory footprint?
> 
> i am trying to run httpd example under lwip package on AT91SAM7X-EK board
> filled with AT91SAM7X256. that microcontroller only have 256KB ROM and
> 64KB RAM.
> 
> i have compiled the example successfully only with PBUF value 10, disable DHCP,
> SLIP, PPP, raw socket support, IP forwarding.
> 
> using arm-eabi-size, httpd binary has size:
> .text : 82740
> .data: 5428
> .bss: 50792
> 
> notice that the sum of .data and .bss is almost 56KB, near 64KB.
> 
> if i increase the PBUF value over 10(default value is 60), compilation process will failed with error that
> is no longer room in .bss because the limitation in 64KB.
> 
> maybe this is out of topic, but i appreciate your assistance...

Well that's hard to say. You would need to ask that question on the lwip 
list. I don't know if there are major differences in memory consumption 
between lwip 1.1.0 and 1.3.1. One advantage of my port is that it can be 
run in a completely polled mode (I call it simple mode), so you can run 
all your network code in a single thread, instead of multiple threads 
(at least 3). The old port did not directly offer that option. This can 
spare you quite a bit of memory (stacks). Notice that when using the 
simple mode, you will have to use the raw APIs (see httpd_simple 
example) and cannot use the netconn and socket APIs. In my project, I 
use the polled mode for the exact same reason (memory) with good results.

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] ecos + lwip

[Mandeep Sandhu]

I'm using ecos-3.0 for current work.

How do you check the version of lwip that ships alongwith this version
of ecos? I'm looking at the Changelog file for this info.

The Changelog shows the current version as 1.1.1 whereas the latest
stable version of lwip released is 1.3.0.

Are there any major issues with 1.1.1 ? (it's seems pretty dated)
Are people using this in production code?

Also, I plan to implement a limited DHCP server. Are "raw sockets" the only
option available? Has anybody used lwip's raw native API to do similar stuff?

Thanks for your time.

Regards,
-mandeep

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Sergei Gavrikov]

Mandeep Sandhu wrote:
> I'm using ecos-3.0 for current work.
> 
> How do you check the version of lwip that ships alongwith this version
> of ecos? I'm looking at the Changelog file for this info.
> 
> The Changelog shows the current version as 1.1.1 whereas the latest
> stable version of lwip released is 1.3.0.

AFAIK, the eCos 3.0/CVS lwIP is something likes lwIP 1.1.0 +.

> Are there any major issues with 1.1.1 ? (it's seems pretty dated)

The latest lwIP 1.3.X has issues with PPP
http://cvs.savannah.gnu.org/viewvc/lwip/CHANGELOG?root=lwip&view=markup

> Are people using this in production code?

STFW

http://en.wikipedia.org/wiki/LwIP

Altera, Analog Devices, Xilinx, etc. use lwIP.

> Also, I plan to implement a limited DHCP server. Are "raw sockets" the
> only option available? Has anybody used lwip's raw native API to do
> similar stuff?

I'm sorry, I do not know about.

Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Mandeep Sandhu]

On Thu, Jul 30, 2009 at 7:22 PM, Sergei
Gavrikov<sergei.gavrikov@gmail.com> wrote:
> Mandeep Sandhu wrote:
>> I'm using ecos-3.0 for current work.
>>
>> How do you check the version of lwip that ships alongwith this version
>> of ecos? I'm looking at the Changelog file for this info.
>>
>> The Changelog shows the current version as 1.1.1 whereas the latest
>> stable version of lwip released is 1.3.0.
>
> AFAIK, the eCos 3.0/CVS lwIP is something likes lwIP 1.1.0 +.

I see the following in the Changelog file
(packages/net/lwip_tcpip/v3_0/ChangeLog)

<snip>
2006-03-26  Uwe Kindler <uwe_kindler@web.de>

    * Updated the complete lwIP source to the latest lwIP
    CVS version 1.1.1
...
...
</snip>

So this means it's using rel 1.1.1...No?

-mandeep

>
>> Are there any major issues with 1.1.1 ? (it's seems pretty dated)
>
> The latest lwIP 1.3.X has issues with PPP
> http://cvs.savannah.gnu.org/viewvc/lwip/CHANGELOG?root=lwip&view=markup
>
>> Are people using this in production code?
>
> STFW
>
> http://en.wikipedia.org/wiki/LwIP
>
> Altera, Analog Devices, Xilinx, etc. use lwIP.
>
>> Also, I plan to implement a limited DHCP server. Are "raw sockets" the
>> only option available? Has anybody used lwip's raw native API to do
>> similar stuff?
>
> I'm sorry, I do not know about.
>
> Sergei
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Sergei Gavrikov]

Mandeep Sandhu wrote:
>
> I see the following in the Changelog file
> (packages/net/lwip_tcpip/v3_0/ChangeLog)
>
> 2006-03-26  Uwe Kindler <uwe_kindler@web.de>
>
>    * Updated the complete lwIP source to the latest lwIP
>    CVS version 1.1.1
>
> So this means it's using rel 1.1.1...No?

Hi Mandeep,

eCos community has a few lists:
http://ecos.sourceware.org/intouch.html

The most of the patches (improvements) are discussed in
in the ecos-patches list, so, it was easy to answer:
http://ecos.sourceware.org/ml/ecos-patches/2006-03/

So, yes, it does mean.

Sergei

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos + lwip

[Mandeep Sandhu]

On Sat, Aug 1, 2009 at 12:26 AM, Sergei
Gavrikov<sergei.gavrikov@gmail.com> wrote:
> Mandeep Sandhu wrote:
>>
>> I see the following in the Changelog file
>> (packages/net/lwip_tcpip/v3_0/ChangeLog)
>>
>> 2006-03-26  Uwe Kindler <uwe_kindler@web.de>
>>
>>    * Updated the complete lwIP source to the latest lwIP
>>    CVS version 1.1.1
>>
>> So this means it's using rel 1.1.1...No?
>
> Hi Mandeep,
>
> eCos community has a few lists:
> http://ecos.sourceware.org/intouch.html
>
> The most of the patches (improvements) are discussed in
> in the ecos-patches list, so, it was easy to answer:
> http://ecos.sourceware.org/ml/ecos-patches/2006-03/
>
> So, yes, it does mean.

Ok. And thanks for pointing me to the intouch list.

Regards,
-mandeep

>
> Sergei
>

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss