Add Full-duplex serial driver for ARM boards

[KarlK90]

Hi there first time contributor here 👋

Description

This pull request adds a new Full-duplex serial driver for chibios based ARM split keyboards. I started this because "my yet to be" released keyboard has the hardware capabilities to connect the rx and tx pins of each half to the corresponding tx and rx pins of the other half. While reading the serial_usart.c code I also noticed that the receive and send buffers have to be cleared for every transaction, which is a limitation of single-wire Half-duplex as the source code stated. This driver tries to improve on the existing Half-duplex driver with the downside that it requires one more conductor:

• No need to flush the send and receive buffers after every transaction
• No need for external pull-up resistors as the tx pin is in push-pull mode
• UART driver in blocking mode to use DMA transfers (not fully asynchronous but hey 🤷)

The driver is implemented in drivers/chibios/serial_usart_duplex.c.

Refactor

Most of the changes are renames of the existing soft_serial naming scheme to just serial. My reasoning is that soft_serial is a legacy from the time where qmk only had the bitbang serial implementation, which changed with the introduction of the usart backed implementation on arm. Therefore I decided to rename the occurrences of soft_serial to just serial namely:

SELECT_SOFT_SERIAL_SPEED -> SELECT_SERIAL_SPEED
SOFT_SERIAL_PIN -> SERIAL_PIN_TX
soft_serial_initiator_init -> serial_initiator_init
soft_serial_target_init -> serial_target_init
soft_serial_transaction -> serial_transaction
soft_serial_get_and_clean_status -> serial_get_and_clean_status
handle_soft_serial_slave -> handle_serial_slave

The renames where done as separate commits. I'am pretty unsure if this changed is to intrusive but I hope this resonates well with the qmk community nevertheless 🙂

Measurements

Setup:

• 8x5 split keyboard
• 33xWS2812 RGB LEDs on each half (PWM Driver)
• GD32F103CB with 72MHz SYSCLK and 72MHz PCLK2
• Ofast optimizations and LTO enabled

Results:

• USART is stable at 2.250.000 Baud/s, 4.500.000 Bauds/s has too many timeouts
• One complete transaction between initiator and target takes 67us
• Matrix scan frequency is about 3800 idle with RGB Lighting on
• Matrix scan frequency is about 4000 idle with RGB Lighting off

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

• None

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[drashna]

You need to rebase your branch locally against the qmk develop branch.
If you need any assistance with just, just ask.

[KarlK90]

Rebased against develop and added a small cosmetic refactoring commit.

[noroadsleft]

This needs to be rebased again, and have the merge conflicts resolved.

[KarlK90]

Rebased onto latest develop branch

[zvecr]

Thanks for the contribution, its an area we have previously discussed a fair bit. So a few things,

1. The Rename refactor should be its own ticket, to which we have previously talked about picking a different name than "serial"
   • The decision on previous discussions was to avoid renaming in the short term to avoid further confusion.
2. We previously tested full duplex while implementing half duplex, and found that it was not any faster.
   • The main advantage I can see is removing the pullup requirement, though the current suggestion is to run half duplex on the same pins as i2c so that you might be able to select that method in the future.
   • The downside is the amount code duplication which is introduced. We also tinkered with rx<->tx swap which works on a limited amount of chips, as another method of i2c interop.
3. Current terminology for the project is still master/slave for the time being, while we decide on [Feature Request] Terminology change for split keyboards #9376. Introducing changes to areas such as the docs should be avoided for now to reduce fragmentation on the issue.

[tzarc]

We previously tested full duplex while implementing half duplex, and found that it was not any faster.

For reference, earlier attempted implementation using TX/RX swap

There's also an earlier (broken) UART driver implementation in the same directory, which got shelved because of the following issue...

It's my understanding that the ChibiOS serial driver wrapped some internal buffer management and the RX interrupt to ensure all data is received -- which was why the Serial driver was used in preference of the UART driver. Conceivably, if there's no "active" call to uartReceiveTimeout in progress (hypothetically say a thread context switch to RGB updates before the next call), any data received would be dropped?

[KarlK90]

Rebased and pushed to latest develop branch. Sorry for letting this go stall for such a long time.

[KarlK90]

Thanks for the contribution, its an area we have previously discussed a fair bit. So a few things,

1. The Rename refactor should be its own ticket, to which we have previously talked about picking a different name than "serial"
   
   * The decision on previous discussions was to avoid renaming in the short term to avoid further confusion.

2. We previously tested full duplex while implementing half duplex, and found that it was not any faster.
   
   * The main advantage I can see is removing the pullup requirement, though the current suggestion is to run half duplex on the same pins as i2c so that you might be able to select that method in the future.
   * The downside is the amount code duplication which is introduced. We also tinkered with rx<->tx swap which works on a limited amount of chips, as another method of i2c interop.

3. Current terminology for the project is still master/slave for the time being, while we decide on #9376. Introducing changes to areas such as the docs should be avoided for now to reduce fragmentation on the issue.

1. Reverted the renaming commits, but used SERIAL_USART_TX_PIN and SERIAL_USART_RX_PIN instead of SOFT_SERIAL_PIN for the driver as it seemed more appropriate then introducing SOFT_SERIAL_PIN_RX.
2. I have to admit that there was no benchmarking involved while claiming those improvements 🙈. Pin swapping is handled using the define SERIAL_USART_PIN_SWAP for this driver.
3. Reverted the changes and used master/slave terminology. But I really would like to change that in the future.

[KarlK90]

We previously tested full duplex while implementing half duplex, and found that it was not any faster.

For reference, earlier attempted implementation using TX/RX swap
There's also an earlier (broken) UART driver implementation in the same directory, which got shelved because of the following issue...

It's my understanding that the ChibiOS serial driver wrapped some internal buffer management and the RX interrupt to ensure all data is received -- which was why the Serial driver was used in preference of the UART driver. Conceivably, if there's no "active" call to uartReceiveTimeout in progress (hypothetically say a thread context switch to RGB updates before the next call), any data received would be dropped?

I think that situation is unlikely to occur because there is no other thread than the main and idle thread right now and the receiving thread has the highest priority of them all. So in theory there should be no context switch back to any other thread until uartReceiveTimeout was called again and the receiving thread put to sleep? Another thought is that everything is synced many thousand times per second, so even if one transfer failed there are plenty of backup transfers. What do you think?

[tzarc]

Confirmed working with a pair of Proton-C boards.

[KarlK90]

Applied the Code Review suggestions, thank you!

[KarlK90]

Should squash the commits once this pr has been accepted?

[tzarc]

Should squash the commits once this pr has been accepted?

GitHub will do so when we merge.

[drashna]

Compiles fine locally.

[XScorpion2]

Confirmed this works really well on the Mun