lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kenny Koller
Subject: Re: [lwip-users] 'Avoiding sys_thread_new' and 'RTOS Integration'
Date: Sun, 09 Oct 2016 18:36:36 +0000

Dirk and Freddy: Thank you for your comments.

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.

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()?

Freddy: Yes you are correct about the FreeRTOS configuration. At the moment I have FreeRTOS 9 running on my STM32F7 and I'm using this technique.

I'll mention that with C++ I do not use either the heap or static allocation. Instead I use placement new. This allows me to allocate memory at compile time but control when the object is constructed. I also use a template to configure the stack size. This is a bit off-topic but I wanted to explain my constraints.

Nice to hear from another C++ embedded engineer. I'm even going so far as to compile with -std=c++14!

From: Kenny Koller <address@hidden>
Subject: [lwip-users] RTOS Integration

Hi Everyone,

I'm starting with some code generated by the ST Cube software for FreeRTOS.

I prefer not to use the FreeRTOS memory manager and the current version
supports static allocation so I pleased to read this:

Since lwIP 1.4.0, semaphore, mutexes and mailbox functions are prototyped
in a way that allows both using pointers or actual OS structures to be
used. This way, memory required for such types can be either allocated in
place (globally or on the stack) or on the heap (allocated internally in
the "*_new()" functions).

Of course I understand what is meant by allocating in place or on the stack
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,

Kenny
 
From: Kenny Koller <address@hidden>
Subject: [lwip-users] Avoiding sys_thread_new

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 far as I can tell there is only one Network task that is created. How
might I rearrange things so that I create that task in my application and
add it's logic?

Does anyone foresee any issues if I don't support this call?

Best regards,

Kenny
 
From: Freddie Chopin <address@hidden>
Subject: Re: [lwip-users] RTOS Integration

Hello Kenny!

You don't need to preallocate anything, but keep in mind that in case
of mailboxes the memory for the mailbox object is usually separate from
the memory for the mailbox contents. In theory you could have both of
these memories allocated in place or on stack, but this way each
mailbox you create would have to have the same size - not very
flexible...

To use this feature I believe you'd need to
set?configSUPPORT_STATIC_ALLOCATION in your configuration and declare
sys_sem_t to be StaticSemaphore_t. The same for mailbox - just
use?StaticQueue_t for sys_mbox_t. Then in the *_new() functions you
just "construct" the objects in provided buffers
with?xSemaphoreCreateCountingStatic() and xQueueCreateStatic().

Due to the thing I mentioned in the first paragraph this gets tricky
with queues, as you'd need to allocate the storage for contents
(pucQueueStorageBuffer argument for?xQueueCreateStatic()) from
somewhere else - heap of preallocated buffers...

Regards,
FCh
 
From: Dirk Ziegelmeier <address@hidden>
Subject: Re: [lwip-users] Avoiding sys_thread_new

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
 
From: Freddie Chopin <address@hidden>
Subject: Re: [lwip-users] Avoiding sys_thread_new

Hello again Kenny!

I'm also a huge fan of C++ (C++11 to be exact) - I'm even writing a
C++11 RTOS for microcontrollers (?http://distortos.org/?) with which
I'm using lwIP right now.

Your assumption that there's only one thread is only partially correct
- in the most common case there in fact is a single thread, but there
may be more - in the lwIP's code base there are actually three calls
to?sys_thread_new(): the TCP/IP thread, SNMP agent and SLIP interface.
If you use some code from the "contrib" packages you can get even more
- there are a few dozen calls to this function in the whole package.
That is because more complex "services" or "applications" are
implemented as a single thread.

So if you are pretty sure that in your case only one thread will be
used, then you can allocate it statically and maybe just
use?sys_thread_new() to post a semaphore or do whatever is needed to
"start" the thread you created. You can even add some assertion to make
sure this function gets called only once.

Regards,
FCh


reply via email to

[Prev in Thread] Current Thread [Next in Thread]