Re: [lwip-users] tcpip thread / no_sys

[Michael Steinberg]

Hello Robert,

thanks for your reply!
Well, currently I'm already using the raw api and do the necessary thread switches "on my own" (just like the netconn adapter api does it really - by posted callbacks to the tcpip thread. but netconn's abilities are only a subset of functionality of the raw api, so I had to go this way, can't remember the exact reason just now, sorry).
So the next step in my eyes is to replace the tcpip-thread alltogether with my own, so I can keep some services which run along the netcode constantly anyways from having to execute these thread boundary hops all the time (a, it's just a waste of cycles, but more importantly, b - less code noise). This includes most importantly my packet delivery code, which is notified from the dma isr. This way I'd have all of this nice and clean in one single thread and less complications. So my plans are to run my thread (which really only replaces the tcpip thread and everybody from outside must go through this thread just like netconn does it with the normal tcpip thread) and use the NO_SYS "api" to run the lwip stack from this thread (and only from this thread).

Does this make sense?

That being said: When I had a walk I had the idea to at least use my own thread-timer code to only notify lwip every ~100ms that it should check its timers (I need to poll the PHY's link status anyways every so often, because the designers of my board felt like they could save on the PHY interrupt line).

Kind Regards,
Michael


Am 05.08.2015 um 00:28 schrieb Robert Deschambault:

Hi,

I don't think that using the raw api is recommended in a threaded environment since the lwIP core is not thread safe.  The better approach is to use the netconn or socket api and there are many examples of how to set this up with freertos and an stm32f4.

We have done multithreaded applications where multiple services (UDP echo service, TCP echo service, custom TCP service, UDP identification service) are running in different threads under cmsis-rtos/rtx and it works really well on an stm32f429. 

We use the raw api in our bootloader using a super loop to emulate "threads" for each "service" because we don't use an rtos in the bootloader.

Bob

On Aug 4, 2015 17:24, "Michael Steinberg" <address@hidden> wrote:

Hello,

during my implementation of a STM32F4 port I'm running across the
situation where I want to roll my own ip-thread, because I have more
base protocols (ptp for instance, more to come) rolling in that service
(want to use raw api) and I'm crossing thread boundaries very often. Now
the NO_SYS api would be a good match to drive lwip from my custom thread
I suppose? According to sources and documentation lwip-tcpip-thread as
well as the no_sys-api both directly incorporate the scheduling theme
instead of passing the problem to a kind of "scheduler api", which could
be exchanged. Now obviously I need timing for my own constructs in my
thread, that way I'm basically having 2 timer schedulers running in my
custom thread (ie. my own and the one lwip is doing). Is there a way to
forward lwip's timing requirements to my "timer service" without hacking
around in lwip's sources or copying/changing it over to my own sources?

Kind regards,
Michael


_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users