WCH CH32V307: UARTs vs USARTs?

[westfw]

The (big) CH32V307 has 8 UARTs, which the datasheet divides into 3 USARTs and 5 UARTs.
But the reference manual fails to tell me what is different between USART and UART.
Are they in fact the same silicon, with the UARTs simply missing external connections for clock?  Or is there something else?

[SiliconWizard]

The USARTs implement a synchronous mode on top of normal async mode. The UARTs are the same, except they don't implement the synchronous mode.

The sync mode allows outputing the clock signal. It becomes close to SPI, except that it still transfers data with start and stop bits and optionally parity.
If you have no use for the sync mode, then there's no difference.

[langwadt]

The USARTs implement a synchronous mode on top of normal async mode. The UARTs are the same, except they don't implement the synchronous mode.

The sync mode allows outputing the clock signal. It becomes close to SPI, except that it still transfers data with start and stop bits and optionally parity.
If you have no use for the sync mode, then there's no difference.

https://static.chipdip.ru/lib/820/DOC059820997.pdf page 284-285  says and shows that the clock is only on data, so it is basically spi

[westfw]

The USARTs implement a synchronous mode on top of normal async mode.

Yes, I understand "the theory."

But the reference manual lists the same block diagram and control registers for both, and doesn't say anything about the CLKEN bit that turns on Synchronous mode being only available on the USARTs.  (There is not clock pin on the package anywhere for the UARTs, but I'm curious if one can set the UART to synchronous mode when one doesn't want start or stop bits, and doesn't care whether the clock is output  (this has been done to generate video, for example.)
(I guess this could be just a documentation/translation issue with the reference manual...)

[SiliconWizard]

- Just look at the datasheet (the RM doesn't list pin functions): there is a USARTx_CK pin only for USART1/2/3 and no _CK pin for any other UART. So at least the clock out pin is only available for USART1 to 3, which is kind of end of the story? (Even if internally all UARTs are the same IP, there's no point in enabling the sync mode for those who can't route the CK signal to any pin.)

- As to using USARTs as SPI, from what I can tell, it still generates start and stop bits but those are generated without the clock apparently, so unless you require a specific level for the data pins when data is not clocked, you could indeed used them as just SPI, only that the throughput will not be completely continuous as opposed to multi-byte SPI, having those pauses for the start and stop bits. (Maybe you can disable them, but haven't seen that.)

They don't seem to allow generating the clock permanently, which could actually be useful in conjunction with a synchronous transmitter with start and stop bits (the start and stop bits acting as framing without the need for an extra CS pin), and some slave devices could benefit from a permanently on clock (something I've already used).

[peter-h]

As to using USARTs as SPI, from what I can tell, it still generates start and stop bits but those are generated without the clock apparently

Is that standard? That's pretty amazing.

I looked up the 32F4 RM and it is the same

The following pin is required to interface in synchronous mode:
CK: Transmitter clock output. This pin outputs the transmitter data clock for
synchronous transmission corresponding to SPI master mode (no clock pulses on start
bit and stop bit, and a software option to send a clock pulse on the last data bit).

Every day is a school day. So basically a USART can be used as an output-only SPI. Damn useful!

[SiliconWizard]

Yes ST MCUs do have similar USARTs too, keep in mind WCH has cloned a lot of ST peripherals so that isn't surprising they have the same behavior.

I have seen "USARTs" in other MCUs. I don't know if it's really standard. Apart from using them as seconday SPI, as I said, that could be useful in some cases *if* they allowed generating the output clock continuously. Unfortunately, they don't seem to have that option. The point being that thanks to start and stop bits, that gives you framing right inside the data lines and so doesn't require an extra line for framing. That can be useful. And the continuous clock can be used for clocking an external device. There are use cases.

But as it is, the clock can't apparently be generated continuously. So it's still "asynchronous" as far as framing goes - detecting data bytes still requires asynchronous framing detection on the other side - but synchronous for the data bits themselves. Slightly odd. But that alleviates the requirement of having an accurate clock on either side. Still a bit half-baked for that, as it doesn't support clock input for a "slave" mode, but only clock output.

[peter-h]

Handy though for driving an LCD, DAC, etc.

A continuous clock output would need a data pattern to indicate start of data, no?

[langwadt]

Handy though for driving an LCD, DAC, etc.

A continuous clock output would need a data pattern to indicate start of data, no?

yes, a start bit like a uart. The ftdi "fast serial interface" basicilly works like that

[SiliconWizard]

Handy though for driving an LCD, DAC, etc.

A continuous clock output would need a data pattern to indicate start of data, no?

As I said start and stop bits are generated.

[peter-h]

Sure, but they are not clocked.

So if there was a continuous clock mode, but no clock edges get generated for the start and stop bits, you would need some logic to detect the leading edge of the start bit.

[SiliconWizard]

Sure, but they are not clocked.

So if there was a continuous clock mode, but no clock edges get generated for the start and stop bits, you would need some logic to detect the leading edge of the start bit.

I wonder what language I'm writing in.

If the clock was continuous, it would be... continuous. That's the whole idea.

As they have implemented it, it is NOT continuous, and they have chosen not to generate it for start and stop bits, probably to make that usable as additional SPI.
If there was an option for making it continuous, the clock would be continuous, so generated while the data lines are idle and of course while start, data and stop bits are generated. Continuous.

[spostma]

...So basically a USART can be used as an output-only SPI. Damn useful!

And (at least Microchip PIC) USARTs seem also to support 9-bit SPI mode,
which can be useful for some LCDs like the ST7735S.