FOR LWIP – RTOS users (posted in lwip forum) Hi all. I have a problem and an idea to solve it. I want discuss here about them. PROBLEM: i worked with lwip over an rtos. i have a task which can get data from network – i.e. a tcp socket – or from other task troght rtos queue. i want to work without blocking call, and i want short latency for data management on this task. now i dit something like this: while(1) ____wait on select (100ms timeout) on tcp connection ____if network data packet is present manage it ____wait on Q read (0ms timeut) ____if internal data packet is present manage it so, in this way, packet from network is managed as soon as possible, data from other task can wait all select timeout if no packet fron net is received the solution could be using socket for BOTH, network data and data from queue, and do something like this: while(1) ____wait on select (100ms timeout) on tcp connection AND queue ____if network data packet is present manage it ____if internal data packet is present manage it I see how lwip code implements socket: 1. lwip_socket create a socket But this function is splitted: _____create netconn _____i = alloc_socket(conn); 2. select unlock itself, when lwip_selscan function finds, in a socket set in fd_set,  lastdata field OR rcvevent field OR sendevent field is change my idea is: 1. function create_socket_queue ____create a RTOS queue ____call alloc_socket(conn), using queue handle as parameter queu, forcing a cast to netconn 2. function senddata_socket_queue(int s) ____call get_socket(int s) ____get conn parameter, force cast to queue handle and send data to it ____increment rcvevent (or sendevent or both) 3. function receivedata_socketqueue ____call get_socket(int s) ____get conn parameter, force cast to queue handle and try to receive data from it ____decrement rcvevent (or sendevent or both) if data was present obviously, using this functions with network socket will be an error, and using queue_socket with conventional socket function will be an error A workaround, could be to build a new structure like this: struct typedef extended_socket { int s; // socket id int type; // can be NET_SOCK or Q_SOCK } and wrap all socket function using extended_socket as parameter, and type field as switch value for calling diferent version of function what is your opinion about this idea? bye, Piero

IMHO, this is too complicated. I would go with two tasks and synchronize them if necessary. Caglar

Hi 1. thsi idea could be necessary if you need to reduce ram usage —-> reduce number of tasks 2. think only one task, which want manage data from multiple socket and multiple queues (for example if you want that queues have different priority)… this idea allows a simple synhronization, using sockets bye Piero

Hi, > 1. thsi idea could be necessary if you need to reduce ram usage —-> reduce number of tasks What’s the point of having tasks then? Besides, freeRTOS tasks do not consume that much memory. Moreoever, coroutines provides less memory usage. > 2. think only one task, which want manage data from multiple socket and multiple queues (for example if you want that  > queues have different priority)… this idea allows a simple synhronization, using sockets Select is not a magical box that you put some things in it and gives you the ready ones. Instead it constantly polls OS to see if anything happens since its last sleep. It will wake-up lets’say at every 100ms to check if there is anything. Besides, it is most helpful on systems where creating a new task is expensive (think of the fork). On the other hand, in freeRTOS you receive at most system tick rate latency without any polling, with the cost of a few extra bytes. And best part is that all is available without any coding on your side. I don’t think you’ll get any improvement with this approach in freeRTOS like you do in BSD or Linux. Regards, Caglar

> What’s the point of having tasks then? Besides, freeRTOS tasks do not consume that much memory. Moreoever, coroutines provides less memory usage.  I need multitask, and i prefer to have no shared stack, so i don’t want  corroutines. I want use tasks, but if i can reduce the number of tasks, i think it could be better! > Select is not a magical box that you put some things in it and gives you the ready ones. Instead it constantly polls OS to see if anything happens since its last sleep. Yes, i know very well this. But, i already have select in a task whcih have to manage packets from multiple connection, so, i have already a task which poll using select, so, why don’t add other data streams from other task to this? i will not add more cpu time, and i will not need another tasks! > in freeRTOS you receive at most system tick rate latency without any polling, with the cost of a few extra bytes. in this case for me it’s not important the latency but the possibility to avoid additional ram and synchronize similar data streams in one point. If you add a task in freertos, you must assign to it a stack space (if you don’t want to use coroutines and shared stack), so your ram usage will grow! Bye Piero

ADDITIONAL NOTE: from freertos web site: http://www.freertos.org/croutine.html "Another consequence of sharing a stack is that calls to API functions that could cause the co-routine to block can only be made from the co-routine function itself – not from within a function called by the co-routine." the lwip stack, is build over a layer which implements some rtos features (create task, wait on sem, … ) the code is complex, and "calls to API (trought the layer) which can block" are made in called functions, it’s impossible, using sockets in a coroutine, avoid the problem above!!!! Richard, Can you confirm this? Thanks

> ADDITIONAL NOTE: ……. I’m studying coroutines api… i’m thinking it’s possible to try to build a lyer for lwip using them! :O) (but i’m not sure) Now, i can see problem only for new task creation, because coroutine function must be write using some strict rules… lwip creates a task for itself, i need to understand how i can avoid problems….. Richard, if you can, help me please! :O| Bye Piero

no… i suspect it’s impossible!!! :O(