GCS_MAVLink: Avoid serial passthrough buffer exhausted/lost data

[brad112358]

Rework the serial port write logic in passthru_timer() to use the return value to detect partial writes due to the serial buffer filling up. Unwritten data is saved in buf1 or buf2 and the write is retried on the next iteration. This avoids lost data when the speed of the two serial ports differs and large blocks of data are sent.

For example, flash programming of ESP MCUs via USB to serial passthrough results in writes of more than 6000 bytes at a time which quickly fills the serial port buffer.

The existing code fails when flashing ELRS receivers via serial passthrough of ELRS which has become a more common need with the mavlink-rc branch of ELRS and the recent support of ESP based receivers in mLRS. This is especially troublesome with AIO flight controllers which may not provide easy access to the serial port connecting the FC to an integrated ELRS receiver.

[olliw42]

excellent !

[IamPete1]

Why not use port->txspace() to only read what there is room to write? I think that would remove the need for the buffers.

[olliw42]

you mean doing something like read_locked(buf, MIN(sizeof(buf),port->txspace()), lock_key); , right?

[brad112358]

Why not use port->txspace() to only read what there is room to write? I think that would remove the need for the buffers.

Another question is why didn't I think of that. The extra memory used was bothering me.

Yes, that is a much better idea and also simplifies the code! I'll start over. :)

[IamPete1]

you mean doing something like read_locked(buf, MIN(sizeof(buf),port->txspace()), lock_key); , right?

Yes, exactly.

[brad112358]

Thanks @IamPete1! I tested and force pushed your much better approach. So simple. It has been pointed out to me that people have been discussing problems flashing ELRS via Ardupilot serial passthroug for more than 2 years. Since it is now such a minimal change, perhaps we can get this into a release soon?

[peterbarker]

You do realise the term "buffer overflow" requires a trigger warning, right?

AFAICS there's no buffer overflow here, the data is simply lost, correct?

[brad112358]

Yes, of course. I should have said buffer exhausted. I will fix the commit comment.

[andyp1per]

I could not update the firmware on my F9P without this - afterwards it was flawless!