Uart wrapup

[beserge]

multi-pin, multi-peripheral support via the config structs and shared DMA

[github-actions[bot]]

Unit Test Results

    1 files  ±0    16 suites  ±0   0s :stopwatch: ±0s 150 tests ±0  150 :heavy_check_mark: ±0  0 :zzz: ±0  0 :x: ±0 

Results for commit 9dcd89f0. ± Comparison against base commit 3b0174e3.

:recycle: This comment has been updated with latest results.

[beserge]

Test Procedure

I ran each of the examples/uart tests on the Daisy Patch. All RX examples were fed by a Field running the Blocking TX example. All TX was verified with my logic analyzer. If it's not mentioned here, it worked fine.

Blocking TX DMA RX / DMA TX Blocking RX

These examples are written with a simple dma flag to avoid the blocking call being interrupted by the dma call.

If you try to write it in a more normal manner

• The DMA interrupts the blocking call.
• It calls the end dma cb, where it tries to start a new DMA.
• This waits forever for HAL_UART_STATE_BUSYRX/TX
• Since we interrupted the blocking call, that flag will never be ready!

I tried using the ScopedIrqBlocker in the BlockingTx/Rx to avoid being interrupted by the DMA. However, this causes the blocking call to get stuck forever. I think there's an internal cb which readies gets the blocking call ready which we're blocking in addition to the dma. Unless we have a good way to block the DMA cb, but not whatever HAL cb we need here, I think the flag based method I used in the tests is OK for now. This is sort of an edge case anyways.

[stephenhensley]

I tried using the ScopedIrqBlocker in the BlockingTx/Rx to avoid being interrupted by the DMA. However, this causes the blocking call to get stuck forever.

This is because the blocking functions use HAL_Delay() which waits for the SysTick variable to increment, and if IRQs are blocked, that will never increment.

I don't think it would be the worst to require that a peripheral use only one method-type (i.e. DMA or blocking) for both rx/tx since the peripheral is linked, but I am open to other solutions. That said, it seems like a limitation of how the HAL's state machine within the UART peripheral is configured.

[CorvusPrudens]

Each of these was tested on USART_1 and USART_3, along with concurrent audio passthrough.

Blocking Receive

• Tested using the Blocking_Receive example. Data was sent from Blocking_Transmit.

Blocking Transmit

• Tested using the Blocking_Transmit example. Data was received by Dma_Receive.

DMA Receive

• Tested using the Dma_Receive example. Data was sent from Blocking_Transmit.

DMA FIFO Receive

• Tested using the Dma_Fifo_Receive example. Data was sent by the Dma_Transmit example. I think this is quite a friendly way to interface with the UART. Definitely my favorite.

DMA Transmit

• Tested using the Dma_Transmit example. Data was sent received by the Dma_Receive example, and its correctness verified over USB (it was very speedy)

Blocking Transmit + DMA Receive

• Tested using the Blocking_Transmit_Dma_Receive example, sent to a blocking passthrough program with different RX, TX buffers to verify.

Dma Transmit + Blocking Receive

• Tested using the Dma_Transmit_Blocking_Receive example, sent to a blocking passthrough program with different RX, TX buffers to verify.

Blocking Transmit + FIFO Receive

• Tested using the Blocking_Transmit_Fifo_Receive example. This one was fun :).

DMA^2

• For some reason, I ran into trouble getting this working with my simple blocking passthrough patch. I may need to revisit this one to ensure it works as expected.

MIDI

• MIDI functionality was tested using the DaisyExamples Patch MIDI example compiled with the latest libDaisy. I sent a simple ascending series of note on messages, and it seemed to rise in pitch as expected.

One notable issue that I don't think is mentioned anywhere is the USART_1 - USB conflict. It seems like any USB usage will prevent USART_1 from working as expected in rather unexpected ways. We should probably make a note of that somewhere in the documentation.

Overall, from my testing, it seems like the functionality is solid.

[stephenhensley]

Just about ready to merge this

just two small things:

• [x] the changelog entries are in the old (now-released) section. So I'm a bit concerned they'll get thrown in there. Let's just do a premerge on that, and make sure the new entries are in the (current) unreleased section.
• [x] let's remove the vscode files from the uart example that has them.