stm32g0x1 uart question

Thread Starter

bug13

Joined Feb 13, 2012
2,002
Hi team

I am looking at a stm32g0x1 part, there is a section in the errata about the usart that I don't quite understand what is means here. Does it mean if the second half of the stop bit is glitch to zero, received data may be corrupted?? (like the second image with RED marking at stop bit).

Errata on section 2.11.1:
Captureuart.PNG

dwg_example_data_frame.png
 

MrChips

Joined Oct 2, 2009
30,707
What you think it means appears to be correct.
The STOP bit is expected to last for at least one bit duration. I have never seen shorter than this.
I suspect that you will never encounter this unless your received data is noisy.
 

Thread Starter

bug13

Joined Feb 13, 2012
2,002
What you think it means appears to be correct.
The STOP bit is expected to last for at least one bit duration. I have never seen shorter than this.
I suspect that you will never encounter this unless your received data is noisy.
Thanks for confirming!
 

nsaspook

Joined Aug 27, 2009
13,079
The funny thing is you really don't need stop bits anymore with modern hardware uarts. It's a mechanical legacy from teletype cam operated printing using mechanical serial to parallel converter state machines. Today it's mainly a check for framing errors.
 
Last edited:

Thread Starter

bug13

Joined Feb 13, 2012
2,002
The funny thing is you really don't need stop bits anymore with modern hardware uarts. It's a mechanical legacy from teletype cam operated printing using mechanical serial to parallel converter state machines. Today it's mainly a check for framing errors.
and Break detection.
Never know about that, but I think we still need the stop bit for compatible reason? (with older hardware, and software??)
 

Thread Starter

bug13

Joined Feb 13, 2012
2,002
While I am at it, why there are other option of stop bit other than 1 stop bit?? When would be a good idea to use 0.5/1.5/2 stop bits? Just a random question.

PS: apart form 0.5 stop bit will be faster than 2 stop bits etc...
 

nsaspook

Joined Aug 27, 2009
13,079
Never know about that, but I think we still need the stop bit for compatible reason? (with older hardware, and software??)
I'm not saying it's not useful to send out of band conditions like a Break or for compatibility.

The main reasons for the variable stop bits was to provide adequate STOP time for the mechanical elements of the data receiver to actually STOP and be ready for the next data element sequence when remote station AC synchronous motors (that powered the mechanical UARTS) were slightly out of sync due to grid frequency shifts and/or printer head delays.
For the old TTY gear, 1.5 was used for mainly BAUDOT gear while 2 was for some gear that had really slow carriage return response times. Most of the times we used the dual carriage return typing cr-cr--lf protocol to be sure the receive gear was ready for actual text.
 

Thread Starter

bug13

Joined Feb 13, 2012
2,002
I'm not saying it's not useful to send out of band conditions like a Break or for compatibility.

The main reasons for the variable stop bits was to provide adequate STOP time for the mechanical elements of the data receiver to actually STOP and be ready for the next data element sequence when remote station AC synchronous motors (that powered the mechanical UARTS) were slightly out of sync due to grid frequency shifts and/or printer head delays.
For the old TTY gear, 1.5 was used for mainly BAUDOT gear while 2 was for some gear that had really slow carriage return response times. Most of the times we used the dual carriage return typing cr-cr--lf protocol to be sure the receive gear was ready for actual text.
Ah, that's a piece of history that I didn't know. But now I do.
 

MrChips

Joined Oct 2, 2009
30,707
Two stop bits were required with slow systems to give the receiver time to capture, store and process the incoming character.

With mechanical printers it was mandatory to send CR before LF in order to give the carriage time to return to the left margin before typing the next character.

Modern UARTs have at least a 1-character buffer to avoid overrun errors. Also processors are much faster at retrieving characters from the buffer and storing, especially now that UARTs can be handled using interrupts or even DMA.

I am routinely running UARTs at 460800 baud and can go even faster.
 

MrChips

Joined Oct 2, 2009
30,707
I paid my dues spending many hours repairing Model 33 Teletype sending and receiving at 110 baud.
We had to use a stroboscope to observe the mechanism to get the pawl adjustments right. Kinda like using an oscilloscope for mechanics.

1607559241755.png

1607559347179.png
 
Top