stm32: Implement Asynchronous UART TX
I am attempting to write large blocks (eg: 2048 bytes) of data to the UART at low baudrates whilst attempting to execute other code. I've discovered that the UART TX is actually blocking until the write is completed. This is a bit of a pain...
This issue is for creating an asynchronous write option for UART. Related to #1533
Probably either interrupt or DMA driven. Should ideally behave like the UART RX does, with a definable buffer in python code, or block as it currently does.
Reading related issues it seems like #1422 has had some success using DMA. Personally, I don't require the callback as I'm not streaming from a file, just an existing bytearray in memory.
I haven't had a chance to read the huge threads on some of the issues I've found so I'm not 100% up to date yet...
RFC: having a standard way to specify UART buffer lengths
Configuring a UART read/write buffer length is important, to trade between memory usage and ability to buffer a lot of data. In some cases you really want a large buffer, and in other cases a small one will be fine. So it makes sense to be able to dynamically configure it.
The stm32 port allows changing the read buffer length via the constructor like UART(1, 9600, read_buf_len=200) Other ports don't currently support this and it would be good to standardise this capability (see eg esp32 request: #3765).
Since stm32 already hase read_buf_len it might be good to use this for the other ports. Then the writing buffer would be configured using write_buf_len.
But, it may also be a good chance to pick better (maybe?) names. For example shorter names like rx_buf_len,tx_buf_len. Or even just rxbuf and txbuf. The latter names are a bit more general and could possibly support passing a preallocated buffer (eg a bytearray) as well as an integer. They could also find (re)use on other peripherals that may need to configure tx/rx buffers.
So the question is: should we stick with read_buf_len and introduce write_buf_len, or move to something like rxbuf and txbuf? (In the latter case, stm32 would retain read_buf_len for compatibility, at least for now.)
Of course, this assumes that such a feature (configuring buffer length) is useful and should be introduced as a general feature of the UART class, which I think it should.