Let's say we set the com-port settings on the PC side with double stop-bit. And then we set the com-port settings on the device side with single stop-bit.
Most PC UARTs under 30 years old only use the "number of stop bits" flag on transmit; on receive they accept any number of stop bits (1 or more). They won't raise a framing error if you are configured for 8N2 and the other end is configured for 8N1 (and the other end won't complain either, since excess stop bits are always acceptable in async serial; they just lower the effective data rate).
I know this for sure for the 16550 (the TI datasheet says "if bit 2 is a logic 1 when either a 6-, 7-, or 8-bit word length is selected, two stop bits are generated. The receiver checks the first stop-bit only, regardless of the number of stop bits selected"), but it's likely also true on common USB-attached UARTs.
If the hardware does detect it, then you'll get a framing error.
If you specifically want to know what the sender is doing: as opposed to making communications work ...
Background
Case 1 is a sender sending back-to-back 8N1 (ASCII 'J' = 0x4a). If the sender is a little slow, we get a short delay (case 2), a whole bit delay (case 3) or more (case 4).
Case 5 is back-to-back 8N2, with a little delay (case 6).
Note that 8N2 is indistinguishable from 8N1 with a 1-bit delay (cases 3 and 5), and so 8N2-with-small-delay is indistinguishable from 8N1-with-longer-delay (cases 4 and 6). Exact 1-bit delay is extremely uncommon.
However, if the baud rate is slow enough or the computer is fast enough, you will have case 1 or 5.
Method 1: Timing
You can tell 8N1 vs 8N2 by timing. If you can get the timing accurate enough, either blocks of data with stopwatch, special program to time incoming bytes (might be tricky in Windows), or oscilloscope.
Method 2: Parity
If your sender is sending back-to-back data, you can use the receiver's parity detection to look at the position of the second stop bit. This extends the byte frame by one bit, and now the receiver will check the bit where the second stop bit would be.
Ideally use "Mark" parity (8M1) which sends a 1 for every parity bit, and in fact sends the identical signal to 8N2. But you can do it with even or odd parity (8E1 or 8O1) if you understand that many incoming bytes will have parity errors. (Very briefly: even parity ensures there an even number of 1s in the data+parity bits; odd gives an odd number.)
If you set the receiver to have parity (best is 8M1 where parity is always "Mark", if your receiver will do it, but 8E1 or 8O1 will also work), then you will have either:
Possible, yes, but it depends on the hardware, and maybe on drivers. It is very unlikely though. Not many hardware chips even verify both stop bits, just one.
The receiver also cannot detect the difference between 1 and 2 stop bits if there is a pause between the frames.
If the hardware checks both stop bits, then only if the other device sends two frames with no gap between them, only then will the receiver see that the second stop bit was violated.
Many UARTs just check if there is a single stop bit and still allows reception of only 1 stop bit even if configured for 2 stop bits, and only the transmit side uses the stop bit setting.
If the hardware detects this error condition in one or both stop bits, the Windows driver will notify user with Framing Error event.
So,
Yes, software gets the information from hardware, if hardware supports checking it, and hardware really checks for both stop bits, and the other device sends two frames back-to-back because a singme frame or two frames sent with a pause in between will not violate the requirement of two stop bits.
Yes, this is exactly same as 1)
Yes if the hardware sends the happened errors to PC, and if the receiver even enforces the requirement for 2 stop bits. Which means there must be a physical UART transmission at some point. Communicating directly to something which looks like COM port but does virtual communication with no UART then there is no physical UART frames so there can be no framing errors as there is no stop bits either.
The Arduino MCU ATmega328P datasheet says that
The Receiver and Transmitter use the same setting. Note that changing the setting of any of these bits will corrupt all ongoing communication for both the Receiver and Transmitter. An FE (Frame Error) will only be detected in cases where the first stop bit is zero.
The STM32F10x MCU reference manual says that
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 NCT6776D Super-I/O IC datasheet says that
NSER (No Stop Bit Error). This bit is set to logical 1 to indicate that the received data have no stop bit. In 16550 mode, it indicates the same condition for the data on the top of the FIFO. When the CPU reads USR, it sets this bit to logical 0.
Thuse it refers to another IC - PC16550D. And the PC16550D datasheet says that
If bit 2 is a logic 0, one Stop bit is generated in the transmitted data. If bit 2 is a logic 1 when a 5-bit word length is selected via bits 0 and 1, one and a half Stop bits are generated. If bit 2 is a logic 1 when either a 6-, 7-, or 8-bit word length is selected, two Stop bits are generated. The Receiver checks the first Stop bit only, regardless of the number of Stop bits selected.
So, in general, it is not customary to control the second stop bit.
