[lwip-users] Avoiding sys_thread_new

2016-10-08 Thread Kenny Koller
I use C++ and prefer to use a task class that I designed. I do not want to allocate these statically. It's not clear to me why the network stack would be concerned with creating threads. I understand that there is a network thread that is created but I don't want it created by sys_thread_new. As f

Re: [lwip-users] Avoiding sys_thread_new

2016-10-08 Thread Dirk Ziegelmeier
There may be other parts of the code that create threads, depending on how you use them - e.g. SNMP supports netconn mode which creates a thread. But you don't need to avoid sys_thread_new - just implement this function so it uses your own class to create a thread. Dirk On Sun, Oct 9, 2016 at 7:

Re: [lwip-users] Avoiding sys_thread_new

2016-10-08 Thread Freddie Chopin
On nie, 2016-10-09 at 05:08 +, Kenny Koller wrote: > I use C++ and prefer to use a task class that I designed. I do not > want to allocate these statically. It's not clear to me why the > network stack would be concerned with creating threads. I understand > that there is a network thread that

Re: [lwip-users] 'Avoiding sys_thread_new' and 'RTOS Integration'

2016-10-09 Thread Kenny Koller
> but in practice how would be be used? It seems that you still need to > preallocate a number of mailboxes or semaphores. Is creating a simple > static array in sys_arch.c and doing some book keeping on which have been > allocated/freed a reasonable approach? > > Regards, > > K

Re: [lwip-users] 'Avoiding sys_thread_new' and 'RTOS Integration'

2016-10-09 Thread Freddie Chopin
On nie, 2016-10-09 at 18:36 +, Kenny Koller wrote: > It seems that the conservative thing to do is use the heap to get > started and as I become comfortable with the code base I'll consider > what is required for static allocation. I'll also just let LWIP > create it's own tasks using the C API

Re: [lwip-users] 'Avoiding sys_thread_new' and 'RTOS Integration'

2016-10-09 Thread Dirk Ziegelmeier
> > > I still don't understand the statement I quoted from the documentation. > For example how would one allocate on the stack for sys_mbox_new()? > ​You can't. All you can do in such cases is count how many mboxes/semaphores/threads etc. you need and allocate their storage statically. A call to

Re: [lwip-users] 'Avoiding sys_thread_new' and 'RTOS Integration'

2016-10-10 Thread Freddie Chopin
On pon, 2016-10-10 at 08:58 +0200, Dirk Ziegelmeier wrote: > You can't. All you can do in such cases is count how many > mboxes/semaphores/threads etc. you need and allocate their storage > statically. A call to sys_mbox_new() just returns "the next one" from > the static allocated ones. This is wh

Re: [lwip-users] 'Avoiding sys_thread_new' and 'RTOS Integration'

2016-10-10 Thread Dirk Ziegelmeier
You are right, this will also work. Even in lwIP 1.4.1 the prototype for these functions was: > err_t sys_sem_new(sys_sem_t *sem, u8_t count); > err_t sys_mbox_new(sys_mbox_t *mbox, int size); > > These functions clearly don't return anything else other than error and > the buffer for semaphore/m