Typical UART stop bit minimum periods - how short can it get?

[HwAoRrDk]

Do microcontroller UARTs typically not require a full length stop bit on received frames? And is that separate from whatever configuration of stop bit length there may be for transmission (e.g. 1, 2, etc.)?

I've been faced with a need to receive 7N1 serial data on a UART that only supports 8- or 9-bit data length. Obviously, this can work because the transmitted stop bit will simply be interpreted as a data MSb of '1' (which can then be masked out), and the inter-frame idle period will serve as the de-facto stop bit. But - I assumed - this relies on that idle period being equal or greater than the baud rate's bit period to qualify as a stop bit.

However, in trying it on a CH32X035, I found I can successfully receive 7N1 data with a de-facto stop bit length approx. 50% of the nominal bit period. This leads me to conclude that the UART is not looking for the full length for it to consider the stop bit valid. The datasheet doesn't contain any information on the subject, so I can only go off observations.

[gamalot]

I guess it just samples each bit at the center of its bit period.

[asmi]

The way UART RX is typically implemented is via over-sampling - meaning incoming line is sampled more often than configured bitrate with the goal is to find an initial high-to-low transition, which is then used as beginning of a start bit, and a counter is starting to wait for a period of time corresponding to a single cycle at configured bitrate, and all subsequent bits are received at those intervals. In other words, the first transition establishes a "time zero" for the purposes of receiving transmission. With that in mind, once transmission is ended, all this circuitry goes back to "waiting for the start bit transition". Since actual sampling frequency has to be at least 4 times the baud rate to be able to reliably detect edges, and usually it's sampled much more often so it can be "debounced" internally to increase immunity to noise. With that in mind, this kind of receiver can theoretically begin receiving a new transmission as early as the next sampling clock period after it detects a stop bit transition.

[PGPG]

Once upon a time (20+ years ago) we were doing such experiments. A conclusion was that receiver issued interrupt (received byte ready) at 1/2 of stop bit period (even if UART was set to transmit 2 stop bits). This allows for speed difference tolerance.

[HwAoRrDk]

The way UART RX is typically implemented is via over-sampling - meaning incoming line is sampled more often than configured bitrate with the goal is to find an initial high-to-low transition

Yes, I am aware that UART receivers use over-sampling; I believe it is typically 16x (although IIRC AVRs offer you the choice to use 8x, a.k.a. "double speed" mode). I'm assuming that generally there will be a minimum number of samples in the logic high state that are required for a UART to accept a valid stop bit.


It occurred to me that, by-and-large, the CH32V-series microcontroller peripherals are clones of STM32 ones, so why not have a look at, say, the classic STM32F103 documentation to see if it has any information about how it handles stop bit sampling?

I think I may have found an answer:

Configurable stop bits during reception

The number of stop bits to be received can be configured through the control bits of Control register 2 - it can be either 1 or 2 in normal mode and 0.5 or 1.5 in Smartcard mode.

• 0.5 stop bit (reception in Smartcard mode): No sampling is done for 0.5 stop bit. As a consequence, no framing error and no break frame can be detected when 0.5 stop bit is selected.
• 1 stop bit: Sampling for 1 stop Bit is done on the 8th, 9th and 10th samples.
• 1.5 stop bits (Smartcard mode): [...] Sampling for 1.5 stop bits is done on the 16th, 17th and 18th samples (1 baud clock period after the beginning of the stop bit). The 1.5 stop bit can be decomposed into 2 parts: one 0.5 baud clock period during which nothing happens, followed by 1 normal stop bit period during which sampling occurs halfway through. [...]
• 2 stop bits: Sampling for 2 stop bits is done on the 8th, 9th and 10th samples of the first stop bit. If a framing error is detected during the first stop bit the framing error flag will be set. The second stop bit is not checked for framing error. The RXNE flag will be set at the end of the first stop bit.

So, if the CH32X035 follows this behaviour, then when it's in 8N1 mode, the stop bit is sampled approx. 50% of the way into the stop bit period. But that doesn't agree with my observed behaviour, because that would bring samples 8,9,10 right over the point at which my next frame's start bits are beginning:



The above is an annotated logic analyser capture of actual 7N1-as-8N1 traffic I'm successfully receiving.

So I guess the CH32V must have different behaviour, and samples the stop bit earlier?

[asmi]

If you have an AWG, I would use it to program in waveforms with different "hold-over" intervals between transmissions to see where the limit is. If it's sufficiently far away, you can be reasonably certain your approach would work.

[PCB.Wiz]

However, in trying it on a CH32X035, I found I can successfully receive 7N1 data with a de-facto stop bit length approx. 50% of the nominal bit period. This leads me to conclude that the UART is not looking for the full length for it to consider the stop bit valid. The datasheet doesn't contain any information on the subject, so I can only go off observations.

Yes, that’s normal, you need some time tolerance for async to work.
If it waited for 100%, an early start bit edge would be missed.

[HwAoRrDk]

If you have an AWG, I would use it to program in waveforms with different "hold-over" intervals between transmissions to see where the limit is. If it's sufficiently far away, you can be reasonably certain your approach would work.

Unfortunately, I do not have an AWG.


I have sent an e-mail to WCH support asking if they can tell me what the sample period/timing is for stop bits. While I assume that their UART peripheral works similarly to ST's, it obviously does not have identical characteristics. I don't want to carry on with trying to receive 7-bit serial data if there's a chance that my current successful experiments are just getting lucky and I'm riding the edge of the envelope.

I've also found that WCH have a sample UART implementation for their PIOC that the CH32X035 supports, which purports to properly support 5- to 8-bit data, so I could in theory use that... if the PIOC-capable pins were re-mappable, which they aren't (I'm already using the pins for something else). That really is the fatal flaw in WCH's programmable-I/O implementation: it only supports 2 pins, and they're generally not re-mappable on most packages (on some you can move one of the two pins), and they're shared with the SWD pins.

[aeg]

If it's really 7N1 and not 7N1.5 or so, I would expect 8N0 reception to eventually lose bit cell position on long series of contiguous bytes. You need to test with a frequency offset between transmitter and receiver.

What baud rate? How about a soft UART?

[bobxyz]

The Atmega processors used on the basic Arduino boards have very good documentation on how their USARTs are implemented.  For example, see pg 193 of https://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf

If the transmitting device is really running 7N1, you may have timing issues when it's transmitting back-to-back characters with no gaps, i.e. only 1 stop bit followed immediately by a start bit.  While the stop bit should be detected OK, at roughly half way into the bit, the following start bit may sometimes occur too early for the detector.  You might be able to tweak the baud rate slightly to shift the sample times and effectively get a little more stop-to-start timing margin.  See the above datasheet and how the baud rate tolerance is calculated.

[langwadt]

what baudrate? a soft uart isn't that hard if you have a spare timer

[peter-h]

A receiving UART typically samples the stop bit in its expected centre (and signals a framing error if it finds it wrong).

But there have been UARTs which have a x16 RX clock and they sample it in say 3 places. I vaguely recall the 85C30 did something like that.

I would not mess with it. Transmit a full size stop bit.

[HwAoRrDk]

I got an answer back from WCH support:

If you configure 8 data bit+1 stop bit, Valid data sampling is conducted at the 8th, 9th, and 10th sampling points.

So it appears their UART is supposed to work in exactly the same way as the STM32 UART. But this doesn't match my experience. As one can see from the screenshot of the logic analyser capture I posted earlier, it can't possibly be sampling a valid stop bit at that point, because that is overlapping the falling edge of the next frame's start bit, and would result in an invalid frame.

Maybe I got my calculations wrong on the sample periods. This is 1200 baud, so bit period is 833 µs, and with 16 samples, that makes a sample interval of 52 µs, which is how I have my marker lines spaced on the capture view.

I am going to have to do some more experimenting...

If the transmitting device is really running 7N1, you may have timing issues when it's transmitting back-to-back characters with no gaps, i.e. only 1 stop bit followed immediately by a start bit.  While the stop bit should be detected OK, at roughly half way into the bit, the following start bit may sometimes occur too early for the detector.

Yes, it's really 7N1; that's what the software configuration is set to (I say "setting", but it's not actually configurable). From what I have found so far, the transmitting device (a vintage PC-based host) does not transmit characters back-to-back - there is always some gap between frames. I'm not entirely sure whether the length of such gaps may differ between units, depending on the speed of CPU, etc.

You might be able to tweak the baud rate slightly to shift the sample times and effectively get a little more stop-to-start timing margin.  See the above datasheet and how the baud rate tolerance is calculated.

Oh, you mean like make it a few percent faster, so that the sample points within each bit are sooner? I do have a fractional baud rate generator on this UART, so I can make it whatever I like.

I would not mess with it. Transmit a full size stop bit.

I can't control what the transmitting side does - it is what it is. It does transmit a full-size stop bit, at 7N1. But I my UART doesn't support 7-bit data (only 8 ), so I'm trying to do what I can.

[Perkele]

How "vintage" are we talking about?
And how about replacing your hardware RX with software UART RX?

[HwAoRrDk]

How "vintage" are we talking about?

Mid 1980s to 1990s.

And how about replacing your hardware RX with software UART RX?

Well, I guess that's always an option. But it'd be a lot of work that I'd prefer to avoid.

[HwAoRrDk]

I've done some more experimentation, and I've discovered two things:

1. The idle time between frames from the transmitting host does actually vary somewhat. It's adequate most of the time, but occasionally it's just the wrong side of the margin for being a valid stop bit. It needs to be at least 470 µs, but sometimes it's a little less.

2. I'm an idiot, because in my code I was forgetting to check the noise error flag as well as frame error and parity error flags.

Code: [Select]

const uint16_t statr = ctx->uart->STATR;

if(ctx->uart->CTLR1 & USART_CTLR1_RXNEIE && statr & USART_STATR_RXNE) {
const int c = ctx->uart->DATAR;
if(!(statr & (USART_STATR_NE | /* <-- this was missing */ USART_STATR_FE | USART_STATR_PE)) && !uart_fifo_is_full(&ctx->rx_fifo)) {
uart_fifo_push(&ctx->rx_fifo, c);
}
}

I had accidentally omitted the USART_STATR_NE from the if-statement expression in the above UART ISR code. For some reason, an invalid stop bit gets flagged as a noise error rather than a frame error?

And the logic analyser capture I showed before? That happened to be one instance where the idle time was shorter and that wasn't actually a valid stop bit, but I was ignoring the error flag. That was why I was confused about how the UART stop bit sampling couldn't be where it was at the 8th, 9th, 10th bit.

[aeg]

a valid stop bit. It needs to be at least 470 µs

OK, 2400 BPS. You're just jerking us around. You could have written a soft UART and been done by now.

[cv007]

Bit-bang a few or more consecutive chars to your own uart for testing- start|7data|1stop|start|7data|1stop. Then see what you get from the uart- data and flags. The real question would be when does start bit detection actually start.

[Perkele]

Well, I guess that's always an option. But it'd be a lot of work that I'd prefer to avoid.

If that vintage box does not a have a dedicated UART for that port, and they're also bit-banging on their side, you'll need to build a "soft" UART anyway.
They can get way more jittery than 5% error margin that's accepted by MCU UARTs.
And if it's not something exotic like 11-bit comms, or custom-length start/stop/sync pulses, you'll find a bunch of examples on github/gitlab/codeberg that you can try and test with.

[HwAoRrDk]

OK, 2400 BPS. You're just jerking us around. You could have written a soft UART and been done by now.

No, 1200 bps. 470 µs is what I calculated to be the 10th sample of a 1200 baud bit that is over-sampled at 16x, not the overall bit period (which for 2400 baud is actually 416 µs).

And my profuse apologies for not being able to pull a fully-formed, tested and robust soft-UART implementation out of my arse on command.

If that vintage box does not a have a dedicated UART for that port, and they're also bit-banging on their side, you'll need to build a "soft" UART anyway.
They can get way more jittery than 5% error margin that's accepted by MCU UARTs.

Fortunately it does have a dedicated UART. It's just a regular W86C451 I/O controller on an ISA card. Like I said, basically just a PC.


I changed my UART configuration to 0.5 stop bits, which, at least if the CH32X035 UART copies the documented STM32 UART behaviour, disables sampling of the stop bit for received frames. I've been testing it a bit, and that seems to reliably receive 7N1. I doubt I'll have problems with losing track on longer streams of frames, because that's not a scenario I have to deal with. I'm only needing to receive short strings of a few bytes at a time. Not much opportunity for things going off the rails when you only have, like, 3 bytes.