Well, perhaps TI was short on examples but you can learn from the apps section and those in the contrib tree.
> I actually didn't quite understand how to use tcp_sent() since [...] When you open a connection (think you can be a server), you set the environment to serve it and then setup an argument to be passed by calling tcp_arg() that depends entirely on you. If you are an http server, you will alloc some memory structure to handle each connection, and that will be passed on calls to callback functions. If you don't need it, you don't use it. The connection has a pcb that is also different from the listening pcb, so the connection pcb is passed as an argument to callback functions. > What you mean by " but remember both must be on the same context" [...] You git it right. All RAW API functions must be called from within the same execution environment (perhaps more proper than 'context'), you can handle everything on the main loop or some people choose to work only interrupt-driven using the Ethernet Rx interrupt. Those functions are not protected for reentrability so you must use them on the same "thread", whether you have an OS or not. (execution environment...) Most work requires sending some content in response to a request or an event. You then put inside the TCP buffer as much as you can send, and if more is left, then, when tcp_sent() informs you that you can send more because the other end ACKed, you keep pushing until it is done. There is the first "intention" to send the contents in some part of your app, in response to the event or the request, and then the real-life sending in response to the tcp_sent() callback. Since you want to send at 2KHz, your "intention" will fire every 500us. TCP might think otherwise, though. _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
