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) - the serial thread sends the data and waits for a response - if a response is received, it is sent through RAW API by calling tcpip_callback (with the correct PCB)
It works quite nice and has the advantage that I only have one thread (aside from the serial threads, of course) instead of 2 for the TCP management. Simon > 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 buffer it as > > > necessary until it has assembled an entire application-level unit, > then > > > put the data (rather than the connection) on a queue and send them to > > > the other task. The other task would then not need to use lwIP at > all, > > > and all the lwIP access would be done from one task (in the callback). > > > > I hope I understood you. The scenario is: I get new data from TCP, I > > put them to (exact) queue, another task reads data and send them to > > serial port. Now the task waits (blocks on semaphore) for reply from > > serial port and forms a reply to tcp. If I dont have a netconn in a > > the task, how can I send reply by TCP? > > Ahh, OK, I didn't realise you needed to write data too. In that case I > would keep all netconn accesses in the task. The sequence would be > something like this: > > 1) you get a netconn_callback on a connection: look up in your own list > which task is responsible for that connection and send it a message > (e.g. via a queue) to say this connection needs attention. You can > include details from the callback, e.g. what type of event it is, but > you shouldn't need to read or write from/to the netconn in the callback > to do any of this. > > 2) the task then pulls things off this queue, and reads (or whatever) > from its netconn, and does whatever it needs to with the data. If len=0 > when it reads, it can close it. > > 3) if the task needs to send data, it can do so directly as it won't be > conflicting with the callback as the callback doesn't touch the netconn > - only forwards the callback details to the appropriate task. > > Kieran > > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
