UART asynchronous communication 115200 spacing 121us between bytes 8N1

[eneuro]

Hello,
I've in AVR UART asynchronous communication at baud rate 115200 (114.3kHz) high level separators 121us wide between bytes (8N1) as shown in attached screenshot   
Are there any requirements in UART asynchronous communication how wide such spacing is allowed at given baud rate ? 
I'd like to send data bytes to HC05 BT module/PC Linux UART from AVR MPU with external quartz 16MHz/8MHz using software serial UART at baud rate 115200 ~114.3kHz and such ~121us separators between bytes gives MPU more time to do other tasks and prepare new data bytes to be transmitted.

[moffy]

There should be no problem with that as long as the bit timing and format are correct, the gap is flexible.

[I wanted a rude username]

As moffy says, technically it's fine.

There is one subtlety you might want to keep in mind though.

Depending on your UART adaptor, this could create a lot of interrupts (and consequently context switches). That's because the UART adaptor might decide that the break in transmission means it should alert the CPU that it has data, even if its buffer isn't at the high water mark. I saw this on a project, where an FTDI USB UART adaptor receiving data in small packets generated an acceptable number of interrupts (about 1,000/second) but a Silicon Labs equivalent generated over 6,500/second. It's a good idea to check with vmstat or similar to see how many interrupts the CPU has to deal with when data are being streamed like this.

[Doctorandus_P]

As has been written already, there is no inherent requirement for this for uart communication. The startbit is the signal that a byte is going to be sent, and each byte has it's own startbit. The stop bit (wich is the same as the idle level) ensures a minimum delay before the the next startbit. but there is no maximum delay.

About the baudrate 115200/114300 = 1.00787 an that is just fine. The theoretical limit is half a bit difference over a byte (Inclusive start /stop bit) so 5%.  Some microcontrollers (for example the ubiquitous arduino's running at 16MHz) can eat up a significant part of that tolerance, and this can cause problems if the clocking on the other side of the wire also has a deviation, but in the opposite direction.

-------------
But there are other considerations too. Higher level protocols stacked on top of of the uart may have additional requirements. For modbus for example the delay between bytes is interpreted as an "end of packet" and can be used to re synchronize if for example a half or damaged packet has been sent. (From memory, I think the maximum allowed delay for modbus is 2 byte times before it times out).

[Peabody]

At the UART level the delay doesn't matter.  UART is "asynchronous" after all.  But are you unable to use the AVR's hardware UART peripheral?

[DavidAlfa]

It's actually beneficial! You can send a byte every 3 months if you wish, there no timeout unless made in the software protocol.
At hardware level, only when a transfer started, it must keep going until the entire byte is sent.

Usually the baudrate frequency has some error, specially with 115200, it's weird frequency so you rarely get it perfect with 8-16MHz reference clock.
For small transfers there's no problem up to 3% error or so, as the receiver has time to resync between transfers, or if the sender is slighly slower than the receiver.

But if you pack the transfers without any gap between them and sender is a bit faster, let's say 115800 instead 115200, the start bit happens sooner every time, until it'll eventually drifts too much for the receiver and causes a transfer error.

For example, I recently did this sending non-stop data using DMA, there was a baudrate error of 1-2% or so.
The first 40 chars or so (I can't tell right now, just an example) went perfect, then got garbage.
Either adding a small software delay of 1-2 bits after few transfers, setting the sender baudrate error to be slower, or perfectly matching the receptor and sender (For example, both @ 1Mbit) worked properly.

The attached picture shows a very exaggerated example, but this can actually happen.
The first two bytes are correctly received but then havoc starts. So sometimes it's important to allow some time between stop and start bits.

[Peabody]

What would happen if you set it to 8N2?  Does the receiver test for the second stop bit,  or does it go back into waiting for a start bit after receiving one stop bit?  If the latter, 8N2 should take care of any reasonably fast transmission rate.

[eneuro]

It's a good idea to check with vmstat or similar to see how many interrupts the CPU has to deal with when data are being streamed like this.

I've Silicon Labs CP2102 on PC Linux, while developing custom app and its Android version will communicate via mentioned HC05 BT module with custom electronics AVR MPUs, so PC Linux is rather development environment, however it would be nice to have Linux version of app - I do not use Window$ at all.
AVR timer is configured for 10kHz, so I should be able send from AVR MPU 5kB of data at baud rate ~114300 since some I'd like to skip every second byte or more if needed.
I've external 16MHz quartz, but for the moment run it as F_CPU 8MHz system clock, so it is decent quality timing in this software UART, but of course I can't fit perfectly into UART baud rate  115200, but it is very close, while I've only around 1% frequency error since we have ~8.750us baud rate period ~114.286kHz, while given baud rate period is:1/115200 ~8.681us, so difference is:  +0.795% ~1% 

[eneuro]

But are you unable to use the AVR's hardware UART peripheral?

Yep, maybe, but sometimes for debug and testing purposes such custom AVR UART software library might better fit your needs when you know exactly how it works and when you have logic analyzer   

[Peabody]

Well, there may be a good reason to use software serial, but the built-in hardware serial does all the bit handling for you, so you ony have to send or receive one byte at a time.  It's literally one-tenth of the processing load of software serial.

[eneuro]

At hardware level, only when a transfer started, it must keep going until the entire byte is sent.

I think that by adding additional spacing between send bytes it should be easier receive such data bytes since we have more time to prepare while next byte will be send ~100us later 
Receiving many bytes with only START spacing is much more difficult since we need very good timing, but... electromagnetic waves at speed of light travel in space less than... only 300 meters within 1us  299792458 m/s * 0.000001 ~299.792m < 300m 

[eneuro]

Well, there may be a good reason to use software serial, but the built-in hardware serial does all the bit handling for you, so you ony have to send or receive one byte at a time. 

Sometimes it might be a problem that in hardware AVR USI UART there is no extra sampling, while hardware have to be configured to probe data byte bits by using reference to the middle of the start bit, while in software UART implementation we can make extra oversampling and for example decide to skip receiving other byte bits at the at the beginning of the transmission when we notice noisy bits signal around the middle of the received data bits 

[eneuro]

The attached picture shows a very exaggerated example, but this can actually happen.

How do you know in the middle of transmission without extra IDLE time spacing between STOP START that  you have high IDLE -> low START instead of next byte high STOP -> low START 



I found something like this and what can I say... it is so sick 

Code: [Select]

Because UART is asynchronous, the transmitter needs to signal that data bits are coming. This is accomplished by using the start bit. The start bit is a transition from the idle high state to a low state, and immediately followed by user data bits.

[DavidAlfa]

UART is rarely used with parity bit.

If everything goes right, you know its a start because you counted the previous start+8 data bits+stop.
If you miss any of these events, then yeah everything goes nuts, any data bit will be treated as start.
Just don't worry about it, it won't fail using that scheme you're using, the receiver has a lot of time to settle down.

[Doctorandus_P]

I have also been bitten by what DavidAlfa described.
When you send a lot of bytes without pause, then slight deviations in the clock frequency can add up and can be a cause for trouble.

For example, I recently did this sending non-stop data using DMA, there was a baudrate error of 1-2% or so.
The first 40 chars or so (I can't tell right now, just an example) went perfect, then got garbage.
Either adding a small software delay of 1-2 bits after few transfers, setting the sender baudrate error to be slower, or perfectly matching the receptor and sender (For example, both @ 1Mbit) worked properly.

But if you pack the transfers without any gap between them and sender is a bit faster, let's say 115800 instead 115200, the start bit happens sooner every time, until it'll eventually drifts too much for the receiver and causes a transfer error.

If the sender is slightly faster then the receiver, then this can happen, but I think most microcontrollers can tolerate this by compensating in the length of the stop bit. I guess that most uC's can tolerate it if the stop bit is only 1/2 to 3/4 of a bit length, but it is hardware dependent. And of course, it is also valid to send with 8n2 and receive with 8n1. It's probably extremely rare to actually check whether that second stop bit is actually present. Note that a stop bit and an idle line are both the same logic level. They look the same on an oscilloscope.

For me, the problem was the other way around. The sender was slower then the receiver, and the receiver had to do some special things and then re-transmit over another uart.
I used a few ISR's to handle uart data. First received about 5 bytes in a circular buffer before I started re-sending them again. It turned out that the original sender was so slow that after 50 or so bytes the circular buffer ran empty before a transmission of a complete packet (which had a variable length) was complete. And instead of just releasing the RS485 transceiver after the circular buffer was empty, I had to actually decode the length of the packet and count all the bytes.

Usually the baudrate frequency has some error, specially with 115200, it's weird frequency so you rarely get it perfect with 8-16MHz reference clock.
For small transfers there's no problem up to 3% error or so, as the receiver has time to resync between transfers, or if the sender is slighly slower than the receiver.

The arduino's with 16MHz clock are especially atrocious. In the old days it was very common to use a crystal that was a multiple of the "traditional" baudrates. Crystals of 1.8432MHz or 11.0592MHz are examples for this. These can generate perfect (well within the generic 200ppm frequency deviation of cheap Crystals.) baudrates. A problem with the "simple" microcontrollers is that they divide the main clock frequency by 16 to generate a clock for the "internal" uart timing. (such as sampling the signal on the 8th of those 16 clocks to sample in the center of a bit). Uarts that do not do this have a thing called a "fractional baudrate generator". All (I guess) STM32 uC's have this, and recently I looked at a datasheet of a new ATtiny and it also has a fractional baudrate generator. With a fractional baudrate generator, there is some jitter in the bit timing, but it's all within normal tolerances, and as a result you can program any baudrate, regardless of the crystal frequency for the uC.  (Some run out of bits for the baudrate divider when they have to generate 150baud from a 20MHz crystal, so there are other limits too).

[Doctorandus_P]

UART is rarely used with parity bit.

No, not really. For simple stuff, often you just throw out some bytes and the receiver will receive them.
If you need more reliable communications then you normally add a higher level protocol. That higher level protocol usually adds a header, which may have a sync byte, the total number of bytes in the packet and adding a CRC to each packet is also common.
And when you already have a CRC, which is much more reliable then parity is not much more then a waste of 10% of bandwidth.

Another annoying thing about parity is that there are so many variants of them (Odd, Even, Mark, Space) and if you set this wrong, then you will get parity errors or even framing errors on the receiving end.

[Doctorandus_P]

How do you know in the middle of transmission without extra IDLE time spacing between STOP START that  you have high IDLE -> low START instead of next byte high STOP -> low START 

When a stream of data is sent in 8n1 format, then each byte is being sent as 10 bits over the wire. (Each byte has an extra start and stop bit).
As a result, in a continuous data stream, every ten bits there is a high to low transition (from stop bit to the start bit of the next byte). This flank, can (and is) often used to correct for small timing deviations, but as described earlier, errors may accumulate and timing may be off too much. When this happens, the receiver looses synchronization and it generates a framing error.

After a framing error, you can attempt to resynchronize on a continuing data stream (Every time there is no negative going flank after 10 bits you know you guessed wrong and must make another guess). There is no guarantee that this sort of resynchronization will ever work, but you can get lucky.

However, when there is some idle time on the data stream, the receiver will just receive zero's until it assumes a byte is received, and will then start waiting for the start of the next start bit. So a bit of idle time (longer then 10 bits) is guaranteed to resynchronize on the next byte sent.

[PCB.Wiz]

Hello,
I've in AVR UART asynchronous communication at baud rate 115200 (114.3kHz) high level separators 121us wide between bytes (8N1) as shown in attached screenshot   

If your host is an AVR, you can set any microsecond delay you like. Don't expect any USB-UART PC to generate this tho, it should receive it ok.

However, your capture is a bit strange, and your SW UART may need fixing.
The start bit looks too wide and you talk about byte separation but your capture shows 16? bits per character ?

[eneuro]

When you send a lot of bytes without pause, then slight deviations in the clock frequency can add up and can be a cause for trouble.

Yep, I've also implemented something like UART reference clock in software where byte 0x55 can be send to another one AVR MPU pin and slave AVR MPU without quartz crystal clock can connect to master to obtain UART frame bits reference timing and simply connect this UART clock source to its own pin change interrupts and synchronize from time to time its internal oscilator 

I've successfully decoded  bytes send from AVR Attiny85 UART custom software in logic analyzer and I was also able to export this data to text file with timestamp and decoded data bytes 

[Kleinstein]

What would happen if you set it to 8N2?  Does the receiver test for the second stop bit,  or does it go back into waiting for a start bit after receiving one stop bit?  If the latter, 8N2 should take care of any reasonably fast transmission rate.

Using 2 stop bits extends the idel phase a little. This can help to better handle the case when the receiver clock is slightly faster. So it sometimes helps and the speed penelty is not yet large.
The extra stop bit is just a longer idle phase between the bytes. So the intended protocol is something like 10 stop bits, which is fine, but usually not directly supported by the hardware. This is the sending side - the receiver side usually does not case about the stop bits.

[eneuro]

If your host is an AVR, you can set any microsecond delay you like.

NOPE, you need to insert nanoseconds delays into your C code on AVR to be as close as possible at given F_CPU eg. 8MHz to given UART baud rate 
In practice it means that when you make changes to your C code what you are looking for is assembler listing and you need to adjust sometimes delays but forget about _delay_us when you want be vely close to given baud rate 115200 on 8MHz AVR mpu - you have to use scope or logic analyzer to see UART TX and calculate  how many AVR mpu system clocks you miss    when you want to fit into ~1% baud rate frequency errors on 8MHz AVR mpu 

[BrianHG]

As I have developed my own UART in verilog, when it comes to PC, yes if you are the only one transmitting, gaps are permitted.

However, if the PC is sending you characters and you want to send your own return characters at the same time back to the PC, you need to sync up your character transmission timing and baud with the characters you are receiving from the PC.  (Called a synchronous UART)  If you do not, the PC will miss some or all of the characters you send.  If your PC's RS232 port and your terminal software supports reporting the problem, you might get a 'Framing Error'.  For example, FTDI's USB-RS232 converters do not report the error, they just drop the characters you are sending to the PC.

My Sync UART here had an illustration of what I had to do to guarantee 0 missed characters when operating at high speed full duplex simultaneous bidirectional coms:
https://www.eevblog.com/forum/fpga/verilog-rs232-uart-and-rs232-debugger-source-code-and-educational-tutorial/
(See the first attached picture which illustrates my full duplex character timing correction required for clean lossless operation)

[BrianHG]

If you are using an FTDI USB-RS232 converter and you want the PC to respond instantly to every single or few characters being received, you can do this using my guide here:

https://www.eevblog.com/forum/fpga/verilog-rs232-uart-and-rs232-debugger-source-code-and-educational-tutorial/msg2801424/#msg2801424

Basically you can modify FTDI's latency interrupt timer from the time data is received until the time your software will eventually be interrupted with new characters in the RX buffer.

[PCB.Wiz]

NOPE, you need to insert nanoseconds delays into your C code on AVR to be as close as possible at given F_CPU eg. 8MHz to given UART baud rate 

I was talking about the delays between characters, not the bit timing.
The OP already has the SW-baud matching sorted.

[PCB.Wiz]

If you are using an FTDI USB-RS232 converter and you want the PC to respond instantly to every single or few characters being received, you can do this using my guide here:

https://www.eevblog.com/forum/fpga/verilog-rs232-uart-and-rs232-debugger-source-code-and-educational-tutorial/msg2801424/#msg2801424

Basically you can modify FTDI's latency interrupt timer from the time data is received until the time your software will eventually be interrupted with new characters in the RX buffer.

For some values of 'instant'      Yes, you can improve a terrible 16ms to a somewhat less worse 1ms.

The FTDI parts are some of the worst I tested, with their SW driver imposed floor of 1ms, which even applies to their FT232H / FT2232H parts.
You also need care that some USB ports may be on motherboard HUB stubs, with worse performance than others.