lwip-devel
[Top][All Lists]
Advanced

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

Re: [lwip-devel] wrap rtos queue in lwip socket


From: Piero 74
Subject: Re: [lwip-devel] wrap rtos queue in lwip socket
Date: Mon, 1 Sep 2008 16:57:29 +0200



2008/9/1 Kieran Mansley <address@hidden>
On Mon, 2008-09-01 at 16:02 +0200, Piero 74 wrote:
> FOR LWIP - RTOS users
>
> 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:

I don't really understand your proposed solution,

I want to use select to block on receiveng data from network or queue task, and i want to do this using a "fake" lwip socket and some additional function, but without change anything in lwip code (select code)
 
but here are a number
of ways you could solve your problem:

1) Don't use the sockets API - if you use the raw API you'll get
callbacks when data become available.

i need BSD socket
 

2) Have more than one thread/task.  Thread "A" reads packets from the
network and writes them to a rtos queue.  Thread "B" reads both this new
rtos queue and the one you already have, and acts appropriately.

i have to kept the numer of task low, for ram usage problem
 

3) Like 2, but Thread "A" reads your rtos queue and writes the data to a
loopback socket.  Thread "B" then uses select() to read both sources.

see above
 

4) Depending on what else you have to do, just poll the socket and the
rtos queue.

i want avoid polling, i prefer that my task wait data using long timeout, for cpu perfromance reasons

Bye,
Piero





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


reply via email to

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