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

[Freddie Chopin]

On nie, 2016-10-09 at 18:36 +0000, 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.

Well - that's the best approach - start with the most conservative path
and when everything works, start changing one thing at a time (;

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

In lwIP's code there's probably something like this:

sys_mbox_t* mailboxPointer;

void tcpip_thread()
{
        sys_mbox_t mailbox;
        sys_mbox_nex(&mailbox, ...);
        mailboxPointer = &mailbox;

        while (1)
        {
                sys_mbox_pop(&mailbox, ...);
                ...
        }
}

Now all "users" may post to the message queue that lives on tcpip
thread's stack. Also note that the mailbox itself may be allocated
statically, but the storage for mailbox contents will usually be
dynamic anyway.

This is more straightforward with semaphores (they don't need separate
storage), but the pattern is more-or-less the same.

Sometimes (most of the time?) these objects are not created on stack,
but just as file-scoped variables (in .bss section) and just
"constructed" with sys_..._new().

Both of these approaches are actually exact equivalents of using
placement new that you mentioned (;

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

Nice (; Using C++ on small embedded sometimes is more or less a trip
into the unknown, as most people will try to convince you that your
approach is not just wrong, but outright heresy, while people who may
sometimes help you (desktop programmers) completely don't understand
the constraints of small embedded systems, so their advices are often
pretty crazy (I remember one advice I got on stackoverflow to create a
std::map<> object and copy it to flash in runtime to save RAM memory -
and I just wanted something like an associative container that would be
ROM-able...).

I think that my RTOS project could suit you, so if you have a while you
could give it a try and let me know what you think (; I've used
FreeRTOS in the past (and other RTOSes), but using any of them with C++
was just a p.i.t.a., so finally - instead of creating yet another set
of C++ wrappers for another RTOS that neglected C++'s existence - I
wrote something in C++. In my opinion it's actually much
easier/cleaner/better to create wrappers for C in C++ than the other
way around - heresy, I know <: But the ability to create threads with
any type and any number of arguments (with regular functions, lambdas
and member functions) is pretty cool (;

Regards,
FCh