UART asynchronous communication 115200 spacing 121us between bytes 8N1

[eneuro]

If you are using an FTDI USB-RS232 converter ....

NOPE, I'm using Silicon Labs CP2102 under PC Linux  .... FTDI? NO thanks 

[eneuro]

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.

I've connected AVR Attiny85 software UART (114285Hz) TX pin to RX pin of Silicon Labs CP2102 USB to PC Linux and I receive on PC from Attiny85 those UART frames 0x41 ('A') by using Linux serial port terminal configured for 115200 baud rate (/dev/ttyUSB0), so it works 



It is time to output from AVR more data bytes with known CRC or MD5 check sums and verify received bytes on PC Linux to see what we get 

[PCB.Wiz]

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% 

Keep in mind, that most USB-UARTS are also not baud perfect, most are 24MHz/N and the crystal less ones, have some small fraction of % jitter.

[eneuro]

Now, on PC Linux  I've dumped to test file avr_uart_frames_0x41.tst  10kB of data UART frames 0x41 received from AVR via CP2102 USB from Linux serial port device /dev/ttyUSB0 than calculated its MD5 checksum:

Code: [Select]

$ dd  iflag=fullblock   if=/dev/ttyUSB0 bs=1k  count=10 of=avr_uart_frames_0x41.tst
10+0 records in
10+0 records out
10240 bytes (10 kB, 10 KiB) copied, 2.10148 s, 4.9 kB/s
$ ls -l avr_uart_frames_0x41.tst
10240 bytes  avr_uart_frames_0x41.tst
$ md5sum avr_uart_frames_0x41.tst
b2a3affdfa9805c917df791087ac93d1  avr_uart_frames_0x41.tst

Later, I've created on PC another file filled with 0x41 bytes and it looks like there were no transmission errors since we have the same MD5 check sums of both files   

Code: [Select]

        unsigned int count= 10240;

        uint8_t byte_tx= 0x41; // ASCII 'A'

        for(unsigned int i=0; i<count; i++ ) {
                fputc(byte_tx, stdout );
        } //for
$ ./avr_uart_frames_0x41 >avr_uart_frames_0x41.out

$ md5sum avr_uart_frames_0x41.out
b2a3affdfa9805c917df791087ac93d1  avr_uart_frames_0x41.out

Additionally as we can see Linux dump to file of 10kB of data from UART USB port /dev/ttyUSB0  was at ~5kB/s speed since we needed around 2s, which is expected, while our real time AVR software UART frames speed is: 114285Hz but we have gaps between frames where only ~43% of UART TX output line is filled with data bits and we need 10bits per each transmited byte, so we get around ~5kB/s UART byte frames speed 

Code: [Select]

10240 bytes (10 kB, 10 KiB) copied, 2.10148 s, 4.9 kB/s
Not so bad 

[BrianHG]

I dont know about linux, but you could try 921600 baud if you want to go faster.  It's an available standard on Windows and with the garbage FTDI junk, I managed a flawless full duplex bidirectional link without any handshaking.

Note: FTDI say they can go faster, but without hardware handshaking, all I got was garbage.

[intabits]

You can go much faster than 115.2KBaud.
I've used an Arduino Nano talking to a Windows PC App at 2MBaud.

But 250KBaud is especially good as the baud rate divisor comes out to a precise integer: 3 (16MHz clock) or 4 (20MHz)
In assembler (for 20MHz):-
BRDIVISOR   EQU   ($CLOCK/(16*$BAUDRATE))-1           ;BAUD RATE DIVISOR
57600      20.70       ;not an integer, but slow enough to work (mostly)
74880      15.69       ;nbg
115200      9.85       ;nbg
128000      8.765      ;nbg
230400      4.43       ;nbg
250000      4.00       ;Perfect! integer and fast
256000      3.88       ;nbg
500000      1.50       ;nbg
1000000     0.25       ;nbg
2000000     -ve        ;nbg

Not sure how the 2MBaud worked (in Arduino IDE C++), but it did:   Serial.begin(2000000);                 

[mikeselectricstuff]

I dont know about linux, but you could try 921600 baud if you want to go faster.  It's an available standard on Windows and with the garbage FTDI junk, I managed a flawless full duplex bidirectional link without any handshaking.

Note: FTDI say they can go faster, but without hardware handshaking, all I got was garbage.

If you're going throuh an FTDI chip. 1M is a better choice than 921600 as it is an exact fraction of the 24MHz clock

[eneuro]

1M is a better choice than 921600 as it is an exact fraction of the 24MHz clock

1M is also an exact fraction of the other clocks 

Code: [Select]

48MHz CP2102
26MHz HC05 BT module
16MHz AVR
 8MHz AVR

Of course it could be better send software UART frame byte faster on AVR and do not loose MPU time for nop delays or other tricky delays to get 1 system clock delay resolution, but it can be more tricky to  write code for AVR since we have only 8 - 16 system clocks per period when 1000000 baud rate is selected but will see what we can do with a little help of assembler inserted code to standard AVR gcc C 

[eneuro]

You can go much faster than 115.2KBaud.

Yep, I've managed to output at 0.5M baud rate  with almost the same AVR C software UART frame TX on Attiny85@8MHz 3.9Vcc with 16MHz external quartz and still a few nop (125ns) delays left to optimize code 

#minicom under Linux  displays send UART TX frames @500K baud rate 8-N-1 received by using CP2102 UART USB /dev/ttyUSB0 

[eneuro]

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.

Yep, Now since I've managed to send UART frames at given baud rates  I was interested in (~115200 250000 500000 and probbaly I can even go 1000000 @ 16MHz AVr MPU) , by using custom AVR C (asm) library, now I'm going to make this asynchronous UART serial communication more reliable and bidirectional one wire 
Idea is as simple as it is:
Add 10k pull up resistors on sender/receiver one wire sides, than change UART software that it will send at the begining of the transmission byte 0x55 (01010101 -> UART frame data in LSB order: 10101010  ) which can be used on receiver side for clock synchronization etc, than each bytes sequence can be finished with one or more MD5 check sum bytes depending on how many bytes were send.
Additionally sender when finishes transmision can release line by changing MPU output pin in high impenance and simply wait a few STOP bit eg. fo confirmation byte send back by receiver by using the same transmission line. eg. it  can reply with 0xFF when everything is OK or do not reply at all, but  send back eg. 0x00 when there were some errors in transmission to let sender know and can also send back message what was wrong - depending on defined protocol.
Pull up resistors on both sides will keep transmission line at high level in a similar way to I2C, but with a difference, that during transmission those pims will be changed again by sender in output mode to drive transmission line not only by connecting O/I pin to ground, but also to logic high, because of 10k rpull up esistors are too big for fast (eg. I2C) communication.
Btw, I mean one wire custom  asynchronous UART serial communication between AVR MPUs which will share the same code, because of this of course will NOT work with classic UART frames implementations, but we should be able send/read UART frames to devices which support classic UART async serial communication at given baud rate 

[eneuro]

Note: FTDI say they can go faster, but without hardware handshaking, all I got was garbage.

Hopefully, I wrote a few lines of AVR C inline assembler code for perfect timing UART at 1M baud rate on 8Mhz F_CPU MPU, so only one NOP instruction was needed but I had to use MPU carry flags to exchange information between instructions while at this MPU speed 8MHz we have only 8 system clocks (1us) to output next UART bit perfectly synchronized with previous one 


Anyway, now we have nice 1Mb UART TX frames from Attiny85 8MHz@3.9Vcc decoded by using 24Mhz Saleae Logic analyzer, but didn't tested this yet with CP2102 USB UART under Linux 

[PCB.Wiz]

Anyway, now we have nice 1Mb UART TX frames from Attiny85 8MHz@3.9Vcc decoded by using 24Mhz Saleae Logic analyzer, but didn't tested this yet with CP2102 USB UART under Linux 

CP2102N manages 1MBd and above just fine, IIRC SiLabs have limited their driver to 1MBd on non 'N' CP2102

[eneuro]

Anyway, now we have nice 1Mb UART TX frames from Attiny85 8MHz@3.9Vcc decoded by using 24Mhz Saleae Logic analyzer, but didn't tested this yet with CP2102 USB UART under Linux 

CP2102N manages 1MBd and above just fine ...

I've connected AVR MPU Atiny85 software UART TX pin via CP2102 USB UART without any 'N' markings (it is only CP2102 etc printed on this IC ) to Linux serial port terminal at port /dev/ttyUSB0 by using  minicom at 1M baud rate 8N1 and it looks good since I send from MPU pseudorandom bytes with prefix 0x55 and stop byte 0xFF with PRNG byte inside 



Howto check which version of CP2102 IC I've in my USB UART  ?

Code: [Select]

[51707.591191] usb 1-1.3: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
[51707.591201] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[51707.591206] usb 1-1.3: Product: CP2102 USB to UART Bridge Controller
[51707.591210] usb 1-1.3: Manufacturer: Silicon Labs
[51707.591213] usb 1-1.3: SerialNumber: 0001
[51707.620907] usbcore: registered new interface driver cp210x
[51707.620919] usbserial: USB Serial support registered for cp210x
[51707.620941] cp210x 1-1.3:1.0: cp210x converter detected
[51707.623063] usb 1-1.3: cp210x converter now attached to ttyUSB0


[PCB.Wiz]

Howto check which version of CP2102 IC I've in my USB UART  ?

It is clear on the marking as CP2102N (as below)
Also, I think their latest drivers refuse to set above 1MBd on CP2102, but allow any 24M/N up to 4MBd on CP2102N
I'd be curious if Linux behaves the same ?

[eneuro]

It is clear on the marking as CP2102N (as below)

Yep, so probably I've classic CP2102 with baud rates 300 up to 1Mb according to their datasheets which is fine since I do not need to go above those baud rates on 8Mhz AVR Attiny85 MPUs 

Anyway, I've checked CP2102N Data Sheet USBXpress™ Family: https://www.silabs.com/documents/public/data-sheets/cp2102n-datasheet.pdf and they says about UART baud rates up to 3Mbaud and there is no information about any limitations since Silicon Labs do support Linux drivers 

[tridac]

At that sort of speed, I would design like a driver, split into two halves. A lower interrupt and mainline parts, with fifo buffer between the two.  Advantages are uart register processing done in the background, in interrupt context, so mainline code can get on with other work. Typically, load the fifo with tx data, enable interrupts and wait until tx complete flag set, or similar...

[eneuro]

At that sort of speed, I would design like a driver, split into two halves.

I was able setup HC05 BT module for slave mode for maximum UART baud rate only 115200 since attempt to configure this thing to 1Mb failed with ERROR:[12]

Code: [Select]

AT+UART=1000000,0,0
ERROR:[12]

AT+UART?
+UART:115200,0,0
OK

Maybe I wll need some kind of buffer, but I do not need to send via this BT module more than 1KB/s data bytes, so I will use on AVR in my software UART implementation something closest lower baud rate to 115200 and it looks like that on 8MHz F_CPU AVR MPU it is:  114285.714 ~114286    < 115200   

UPDATE: I've configured HC05 BT module for UART 921600 baud rate in slave mode 

Code: [Select]

+UART:921600,0,0
OK


[eneuro]

I dont know about linux, but you could try 921600 baud if you want to go faster.

Yep, I've tried again setup HC05 BT module for something faster than 115200 and it looks like it accepted baud rate 921600 but failed when tried 1000000
I didn't expected this but that is fine lets tune AVR UART software code to something closest to 921600  baud rate on AVR Attiny85 8MHz@3.7Vcc (powered directly from 18650 Li-on battery with 16MHz quartz on PCB) 

Code: [Select]

+ROLE:0
OK
+UART:921600,0,0
OK


[PCB.Wiz]

I didn't expected this but that is fine lets tune AVR UART software code to something closest to 921600  baud rate on AVR Attiny85 8MHz@3.7Vcc (powered directly from 18650 Li-on battery with 16MHz quartz on PCB) 

I thought you had deliberate delays anyway, because the MCU was already to slow ?
Making the UART faster is going to give diminishing returns.
921600 from 8M is going to be off by 3.5%, unless you use fractional baud / unrolled loop approach. (or change xtal to 14.7546Mhz)
The error per bit is 39.93ns, and you have 125ns granularity, so as the error creeps, after a couple of bits you snap to the closest 125ns edge, 

[eneuro]

The error per bit is 39.93ns, and you have 125ns granularity, so as the error creeps, after a couple of bits you snap to the closest 125ns edge,

Hopefully, since communication speed is not critical for me at 921600bps baud rate, after a couple of LSB bits in one byte I can send last four as 0xF, than in second byte again four MSB bits first than fill rest of 2nd byte by sending 0xF, so instead of sending 1 byte I need to send 2 bytes but I can do it much faster at close to 1Mbps than by using 115200bps baud rate 

[PCB.Wiz]

Hopefully, since communication speed is not critical for me at 921600bps baud rate, after a couple of LSB bits in one byte I can send last four as 0xF, than in second byte again four MSB bits first than fill rest of 2nd byte by sending 0xF, so instead of sending 1 byte I need to send 2 bytes but I can do it much faster at close to 1Mbps than by using 115200bps baud rate 

That's sounding very convoluted.
You could look for intermediate bauds, between 115200 and 921600  ?
Or, unroll the SW baud loop, so you can do the fractional baud above, which would work ok.

A calculator gives the jitter results for fraction baud, see how the drift does not accumulate, by careful choices of when to do /8 and /9 .

 
(1/921600)-(1/(8M/9))              Diff = -39.9ns
(2/921600)-((1/(8M/9))+(1/(8M/8))) Diff =  45.1ns
(3/921600)-((2/(8M/9))+(1/(8M/8))) Diff =  52.0ns
(4/921600)-((3/(8M/9))+(1/(8M/8))) Diff = -34.7ns
(5/921600)-((3/(8M/9))+(2/(8M/8))) Diff =  50.3ns
(6/921600)-((4/(8M/9))+(2/(8M/8))) Diff =  10.4ns
(7/921600)-((5/(8M/9))+(2/(8M/8))) Diff = -29.5ns
(8/921600)-((5/(8M/9))+(3/(8M/8))) Diff =  55.5ns
(9/921600)-((6/(8M/9))+(3/(8M/8))) Diff =  15.6ns
(10/921600)-((7/(8M/9))+(3/(8M/8)))Diff = -24.3ns

[gnuarm]

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.

The purpose of the start and stop bits is to align the data reception, to the data transmission.  This should be all the alignment required.  If you need to add extra spacing between bytes, it is either an electrical issue with your connections (such as too much wire adding too much capacitance slowing the transmission times) or your receiver simply can't read the received data from the UART quickly enough.  In the case of the latter, an error flag for overrun should be set in the UART. 

If everything else is working properly, the start bit of the next character can follow immediately on the end of the stop bit of the previous character.

BTW, your diagram seems to show two levels for each transmitted data bit.

[eneuro]

BTW, your diagram seems to show two levels for each transmitted data bit.

Yep, It was made only to show gaps ~100uS 0.1ms between next UART frame and it doesn't matter what is inside between START green - STOP red  bits 

[eneuro]

Or, unroll the SW baud loop, so you can do the fractional baud above, which would work ok.

Nope, you  can't unroll the SW baud loop better than in was done in inline assembler, since I do not know AVR instruction set which could make delay 1/2 or 1/3 system clock at F_CPU 8MHz 
I had to add only two NOP 1 clk instructions  to inline C assembler (to avoid any gcc optymalizations when -Os is given for size optimization) code shown before for 1Mb optimized 1us perfect timed UART TX frames which gives us baud rate period error for 921600bps on 8MHz AVR MPU:

Code: [Select]

|100*(  1.0/(1.0/1000000 +1.0/8000000 )  -921600)/921600|  [%] =
[b]~3.5%[/b]

NOTE: 1.0/8000000 = 125ns is 1 clk instruction NOP for example...
so when we use 16Mhz AVR MPU than this baud rate period error will be lower ~2.1%

When we use 12MHz AVR MPU than this baud rate period will be ~1.6% 

Code: [Select]

(  1.0/(1.0/1000000 +1.0/12000000) -921600 )/921600 = 0.0016025641 ~1.6% @ ~923077 software AVR MPU UART baud rate 

BTW: HC05 BT module has 26MHz external clock on PCB 

Code: [Select]

(  1.0/(1.0/1000000 +1.0/13000000)-921600 )/921600 = 0.007564
~1% baud rate error @ 13MHz AVR MPU

[BrianHG]

When we use 12MHz AVR MPU than this baud rate period will be ~1.6% 

Code: [Select]

(  1.0/(1.0/1000000 +1.0/12000000) -921600 )/921600 = 0.0016025641 ~1.6% @ ~923077 software AVR MPU UART baud rate 

Are you sure your math is correct?
For example, try replacing the 12MHz with 120MHz.  The %error should be the same or less, but it is not.