Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:   +16 +0.005% RPI_PICO
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS

@dpgeorge This works just fine for TX. Currently on the RX side there is a race condition, for which I'd appreciate your suggestions.

Incoming data will raise an interrupt but in general the DMA controller will process the bytes much faster than the CPU can respond, so for small amounts of data this is not an issue. The problem comes when more data arrives after the interrupt handler has started; in this case the interrupt handler and the DMA controller will both try to read data from the FIFO, with some bytes going to each. It looks like we need a way to suppress the RX interrupt handler.

One possible (fairly clean) solution to this would be to add a .close() method to the UART class that allows the user to continue to reference a UART but disables processing through the software path, so that the DMA controller can have exclusive access. I would like to hear your thoughts before proceeding.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.36%. Comparing base (9feb068) to head (89b6f89).
⚠️ Report is 2779 commits behind head on master.

@@            Coverage Diff             @@
##           master   #13378      +/-   ##
==========================================
- Coverage   98.40%   98.36%   -0.05%     
==========================================
  Files         159      159              
  Lines       21088    21088              
==========================================
- Hits        20752    20743       -9     
- Misses        336      345       +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

One possible (fairly clean) solution to this would be to add a .close() method to the UART class

An alternative would be to add a .active() method, as used by a bunch of other devices, and just have it enable or disable the UART interrupt handler.

Having the DMA to transfer the data is just one element of the game. Information about how much data has been transferred is equally important, especially for receive.
That said I would not consider DMA for UART as a huge benefit over the IRQ based solution. For SPI the speed gain is more valuable.

@robert-hh The amount of data received can trivially be read by looking at the value in the attribute dma.count since this gets decremented for each character transferred.

This is an automated heads-up that we've just merged a Pull Request
that removes the STATIC macro from MicroPython's C API.

See #13763

A search suggests this PR might apply the STATIC macro to some C code. If it
does, then next time you rebase the PR (or merge from master) then you should
please replace all the STATIC keywords with static.

Although this is an automated message, feel free to @-reply to me directly if
you have any questions about this.

This works just fine for TX. Currently on the RX side there is a race condition, for which I'd appreciate your suggestions.

One suggestion: when Python code gets the buffer of the UART (eg via memoryview(uart), or passing to DMA) and it's for reading only, then disable RX interrupts on the UART. They can then be reenabled by doing uart.init(...) if needed by the user. Then, document this behaviour. I think if users are using this advanced feature (passing UART to DMA) they can read the docs and understand exactly how interrupts work in this scenario.