Addition of flag to indicate Serial TX complete.

[Rippatec]

Hi,
It would be useful to have a method that allows checking if the serial-TX system is all-done.
I know that Serial.flush() does allow this but it involves waiting...
A simple flag to check (set/cleared?) after the last byte is gone would be very useful as it would allow doing other things instead of waiting.
ie, when a 40-byte message is in the TX buffer to send, flag gets set to indicate its happening and when the last byte exits.. flag is cleared.
This functionality would be useful and it has come up quite a few times (for me at least) so as a feature I think it would be a good addition.
I dug through the serial code as best I could and it seem that I could do this by checking various registers and buffers but this would almost be duplicating code that already exists in the serial routines which is wasteful of code-space in an already limited chip (ATtiny1614).
The sensible place to do it would be in the serial code itself.
Is this a feature that would be difficult or even worth implementing?
Thanks,
Stu.

[SpenceKonde]

Provided that you know the serial port has sent at least one byte of data (and if you don't know whether you've sent anything since poweron, yet you need to make sure you've finished sending? Yes we track that in a dense thicket of flags in one of the private member variables so that calling flush() won't hang forever, but I don't belive we expose that.

But as long as you know at least one byte, when availableForWrite() == buffer size that means that it's on it's last 1 or maybe 2 bytes.

To see if it's done sending those, check if (USARTn.STATUS & 0x40) - that's the transmit complete interrupt, TXCIF flag I think it's USART_TXCIF_bm using the names). We don't use the TXC interrupt (except when LBME = 1 - in that case likely the de-facto standard ODME LBME single-wire half-duplex configuration, see the Serial reference (megaavr/extras/Ref_Serial.md) - we don't test for the condition that the characters we tried to send was not what appeared on the line at the time because the other device tried to transmit at exactly the same time (Which, uh, really shouldn't happen if the protocol is well designed, anyway) because we don't know how to handle it because there isn't a 1-size-fits all solution to this issue - in any event we don't clear TXCIF in the interrupt in this case, we instead disable the interrupt so that TXCIF is still a reliable indicator of the send being completed.

So I don't think there is a feature to add here. The functionality is already available.

[Rippatec]

OK, thanks for the clarification. I'll see if I can get it to work for me.
Stewie.