Data transfer serial port, and waiting

[megax]

Hi!

I want to do something where I want to put the processor in pause mode in the receive callback function. I want to send the incoming data via serial, but I need to check if the other side has successfully received it or if the buffer is full. And until then I need to wait for the incoming data to be processed. Thread delay is probably not a good solution. I have a question, is there a solution for this? Or can I somehow modify the lib to make this work?

#56 I read this, but I don't know if it can work in my case.

[mathieucarbou]

Hi,

The data received by client.onData()callback has to be consumed by the callback, otherwise lost.
And since you are within the scope of the async_tcp task, you cannot pause it.
Instead, you have to exit as fast as you can.

But you can control the ack mechanism instead by only sending acks once you know the peer has received.

We have made an exemple of that in ESPAsyncWebServer project with a tunnel, which is streaming back through websocket the content of a website fetched using an asynchronous client.

when async client onPacket cb is called, we are sending the bytes through websocket and we ack the bytes when the ws buffer is destroyed (which means it was dequeued and sent).

https://github.com/ESP32Async/ESPAsyncWebServer/blob/main/examples/AsyncTunnel/AsyncTunnel.ino#L139-L155

[megax]

Thank you for the information. This is not sure if it will help me. My problem is that my Serial buffer can fill up. I send from ESP to Teensy. And I have a fixed buffer. If I upload too fast, it can fill up. In this case, I suffer data loss. If I can't pause the incoming data stream. That's why I want to solve it somehow. If it's not possible, then I won't force it, then I'll look for some other solution.

[mathieucarbou]

you are able to slow down the sending by sending acks when you decide, but you wont be able to control the incoming buffer size indeed so if you cannot forward the total amount of bytes received, you will need to store the buffer in a async queue that another task will process, if cannot send as a hole, will retry later with the remaining and will send back acks when queue is finished.
I am saying queue but no need for a queue, just a buffer and index and another task. You could try that.

but the rule is: no blocking inside a async_tcp callback. you need to exit asap.

[megax]

Thanks for the feedback. I'll give it a try.