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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 > >
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
