Peripherals that can be split, should have their config split accordingly

[MabezDev]

See #1668 (comment) for context. I think this only affects Uart, from the stabilized driver list.

With this setup, and the ideas following from that, eventually we can add split support where:

• The full Uart takes Config
• The control struct from split takes the full Config
• UartRx take the RxConfig
• UartTx takes the TxConfig

The important thing here is that we structure the config in a way that allows us to do something like this post 1.0.

We should also update the API docs accordingly.

[bugadani]

The control struct from split takes the full Config

This part is dangerous. We shouldn't allow configuring parts of the driver that may be in active use.

[playfulFence]

Maybe we should have only runtime-modifiable things in that Control struct?

[bugadani]

Maybe we should have only runtime-modifiable things in that Control struct?

You might want to specify that, as all config options are runtime-modifiable currently.

[playfulFence]

Does it make sense to runtime-modify StopBits, Parity or DataBits? Maybe it does though, not saying it doesn't 😄
Maybe only baudrate and clock source should be in Control structure?

[bugadani]

Would you say it safe to modify the clock source, or the baud rate, when the peripheral is sending or receiving data? (Yes this is a trick question, UART is always receiving data)

[MabezDev]

Would you say it safe to modify the clock source, or the baud rate, when the peripheral is sending or receiving data? (Yes this is a trick question, UART is always receiving data)

As you mentioned, UART is always listening, so this is always something the user will have to handle when changing almost anything related to uart protocol - we can't really help them.

For future peripherals where the protocol isn't always listening, we can add some internal locking to avoid starting/stopping tx/rx halves whilst the protocol is being changed.

This is all a bit orthogonal to the issue at hand here (unless I'm missing the point you're getting at), we're just prepping the configuration layout for the future?

[bugadani]

As you mentioned, UART is always listening, so this is always something the user will have to handle when changing almost anything related to uart protocol - we can't really help them.

Let me phrase this in another way: a shared configuration object, without locking in the driver, is UB if the split halves have their own partial configuration functions.

The clock source/baud rate thing is somewhat orthogonal, but still related to what we allow to do, and it's a direct response to the question Kirill asked.

I'm pretty much okay with separate config halves. We can handle in the Rx driver that we must work around some things - like we can disconnect the RX pin for the duration of the configuration. But we shouldn't allow some external piece of code to do that, I think.

[MabezDev]

Let me phrase this in another way: a shared configuration object, without locking in the driver, is UB if the split halves have their own partial configuration functions.

I agree, we'd need to have some form of locking/communication to make global uart changes to whilst rx/tx are split.

But we shouldn't allow some external piece of code to do that, I think.

I think I agree, but I also don't think I'm 100% certain what you mean by this. In my head, all this should be internal to the HAL. Once we have a split with tx, rx and control, tx & rx should be able to manage their own config themselves, but control will need some way to tell the tx/rx halves we're about to make global changes prepare for it. As you mentioned this might include disconnecting the pin during the configuration. Is this the sort of thing you meant?

[playfulFence]

Currently, this issue is not applicable to any other peripheral driver we plan to stabilize by [email protected], so I'm closing this issue.