Finally I wrote the server with RAW API and tcpip_callback function. It's
working ok, but there is a one strange thing. Sending reply to the client
takes about 250 - 1000 ms (taken from Wireshark). Sending reply directly
(without tcpip_callback) takes less time (max 2 - 5 ms). Have you got
Finally I wrote the server with RAW API and tcpip_callback function. It's
working ok, but there is a one strange thing. Sending reply to the client
takes about 250 - 1000 ms (taken from Wireshark). Sending reply directly
(without tcpip_callback) takes less time (max 2 - 5 ms). Have you got
Hi,
I'm using netconn API with callback function. In callback function I check the
parameter len - if is greater than zero, I put a pointer to the netconn to
queue. Another task reads the queue and use that netconn to parse data and send
reply. This operation may takes several seconds. What if
The wiki page is indeed very confusing. I recently added some lines to
rawapi.txt, but that new version is only available through CVS, yet.
The baseline is that what you are doing is not really supported: sockets AND
netconns are not allowed to be shared between multiple threads. This is a
On Wed, 2009-05-13 at 10:52 +0200, ncoage wrote:
The simplest way of dealing with the len=0 case would be to still put
the netconn on your queue, together with some state that will allow the
other task to know that this connection should be closed, and get the
other task to delete it.
I
I thought about that solution, but my application is more complex.
There are three tasks, each of them communicates with his own serial
port. When new data come from TCP, I check specific flag, which
determines wich task (serial port) must get rest of the data frame.
Where do you get
On Wed, 2009-05-13 at 11:25 +0200, ncoage wrote:
I thought about that solution, but my application is more complex.
There are three tasks, each of them communicates with his own serial
port. When new data come from TCP, I check specific flag, which
determines wich task (serial port)
Thank you for your reply. I need more time to analize what you wrote :).
But now I have a question, you wrote:
The most reliable way to implement what you describe would be for the
callback connection to read all the data, reassemble and buffer it as
necessary until it has assembled an entire
On Wed, 2009-05-13 at 12:19 +0200, ncoage wrote:
Thank you for your reply. I need more time to analize what you wrote :).
But now I have a question, you wrote:
The most reliable way to implement what you describe would be for the
callback connection to read all the data, reassemble and
Sounds pretty much like the same like a TCP-to-serial converter I wrote on
lwIP. I did it with the raw API though:
- I have a tcp_recv-callback that waits until a complete packet is received
- then that packet is parsed and sent to the right serial thread (together with
the PCB, for responses)
Maybe I'm wrong, but my application can't work like you said. I have 3 serial
ports, if one port has just send data and now is waiting for reply (several
seconds), another can't be blocked. So I must use seperate tasks for each
serial port.
When I receive data from tcp I have to get to know
I didn't want to tell you how to write the serial part, however, the connection
to lwIP stays the same: assemble a packet for serial either in netconn-recv or
raw-API recv-callback and put it on a queue to the correct serial task.
The problem you then have is you need to know the correct pcb
Why don't you just put mutexes around the appropriate code in the
sockets library (if you're at that level) or the netconn library (if
you're at that level).
On May 13, 2009, at 8:04 AM, ncoage wrote:
Maybe I'm wrong, but my application can't work like you said. I
have 3 serial ports, if
13 matches
Mail list logo
