Understanding Baud rate

[JeffreyPeter]

What is Baudrate ? What is the adv of high/low baud rate?

 

[JimB]

Have a look here:
https://en.wikipedia.org/wiki/Baud

For simple communication systems, the baud rate is the number of bits per second.

A higher baud rate will move data faster than a lower baud rate.

The higher the baud rate, the greater the bandwidth needed for the signalling channel.
A high rate will need a wide bandwidth and is generally not very tolerant of noise.
A low rate can use a narrow bandwidth and depending on the coding scheme can be very tolerant of noise in the signalling channel.

JimB

 

[Jon Wilder]

With serial communications, bits are sent/received 1 bit at a time and each bit is sent/received at a specific time interval. Baud rate, as mentioned above, is just the measure of how many bits can be sent/received in 1 second. This determines the period of each bit (i.e. the time interval between each bit being sent/received) and the period is equal to 1/Baud. Example, a baud rate of 9600 would have a period of 1 / 9600 = 104.1uS (microseconds). This means that 1 bit is being sent/received every 104.1uS.

With asynchronous serial communications, each serial device times the bits via its own internal bit timer (no external clock signal provided). The baud rates at both the tx and rx ends must be pre-agreed upon and the two must match. If they do not match, you will either get framing errors or the received byte will not match the byte that was transmitted.

With synchronous serial, you have a master device and one or more slave devices, and an external bit clock signal that is generated by the master device. Both can transmit and receive, but only the master can generate the external clock signal. With I2C, you can have one or more master devices with just two wires. One for bi-directional data and one for the serial clock. Again, only the master can generate the external bit clock signal.

 

[JeffreyPeter]

Do i have to generate a delay of 104.1 us before sending the each bit in UArt ? or its done automatically by the timer ?

 

[3v0]

A UART is a hardware device. You give it a byte and it does all the work to send it out serially. When it is finished it will set a flag or generate an interrupt. But it is up to you to setup the UART to transmit at the correct baud rate.

You can fake a UART in software which is know as bit banging. If you do that then you have to set the output high/low and generate the delays.

 

[JeffreyPeter]

is the baud rate the time taken to transmit each bit to the receiver's buffer ?

 

[ericgibbs]

is the baud rate the time taken to transmit each bit to the receiver's buffer ?

hi,
The Baud rate is the effective Bit rate.

Consider a typical Byte of data, which is made up of 8 bits , the Uart adds a Start bit to the front of the 8 bits and a Stop bit to the end, so thats 10 bits.

Assume a Baud rate of 9600, divide that by the 10bits, gives a Byte rate of 9600/10 = 960 Byte [ characters/sec]

E.

 

[JeffreyPeter]

Assume a Baud rate of 9600, divide that by the 10bits, gives a Byte rate of 9600/10 = 960 Byte [ characters/sec]

So is it practically possible to send 960 bytes in 1 sec using UART ?

 

[ericgibbs]

So is it practically possible to send 960 bytes in 1 sec using UART ?

If required, the Baud rate be greatly increased by using the recognised standard rates.

https://digital.ni.com/public.nsf/allkb/D37754FFA24F7C3F86256706005B9BE7

Consider 115200 Baud, thats approx a max of 11,520 Characters/sec

 

[Jon Wilder]

Jeffrey...the UART either has its own dedicated timer (the SPBRG register on a PIC) or it will use one of the on-chip hardware timers (8051 uses Timer 1) for the baud timer. Check the data sheet for your specific processor.

Once the UART is set up, you just write the byte that is being sent to a transmit buffer and the hardware does the rest.

960 bits ber second is a bit slow, but is certainly possible, although it would require an odd value crystal frequency of 11.059MHz for lowest error percentage. A PIC with a 4MHz crystal and a value of 64 written to the SPBRG register will give a bit rate of 961.54 bits per second. If you were wanting to do 9600 bits per second, you would set the baud rate generator up in high speed mode (write value 0x24 to register TXSTA for high speed BRG mode) and write the value of 25 to SPBRG. For 8051, most use a 11.059MHz crystal for 9600bps and initialize timer 1 in 8-bit auto reload with a reload value of 253 (0xFD). The reload value on 8051 must be written to register TH1.

 

[ericgibbs]

hi Jon

Jeff asked about 960 Bytes per second, 'not 960 Bits per second is a bit slow.'

E

 

[Jon Wilder]

Yep I see it now...misread it the first time.

Yes, 960 bytes per second translates to a baud rate of 9600bps (10 bits per byte including the start/stop bits - the UART automatically generates the start/stop bits).

 

[KeepItSimpleStupid]

Just an obsolete kind of note. Mechanical Teletypes has 2 stop bits rather than 1 at 110 baud. Yep, creepy slow.
The IBM selectric typewriter/terminal used 1.5 Stop bits for it's 134.5 Baud.

 

[JeffreyPeter]

Thanks...
I really appreciate your help

 

[Mr RB]

Using more than one stop bit is a good idea, as it allows the receiver to re-sync if the receiver baudrate is slightly slower than the transmittter baudrate. If you use exactly one stop bit the receiver will drift in phase over multiple bytes.

Using 1.5 stop bits allows the receiver to be up to 5% slow and still resync after every byte.

 

[JeffreyPeter]

how to use more than one stop bit ?

 

[JimB]

how to use more than one stop bit ?

It is done during UART configuration.
There are bits to set for 1, 1.5 or 2 stop bit operation.

But, you would only use more than one stop bit when driving an old mechanical teletype.
As a result, newer UARTs (USART EUSART) may not have the option of setting more than one stop bit.

JimB

 

[Mr RB]

You can do it manually by putting any small delay between bytes that you send.

If speed is not the most important factor you can use a nice large delay between bytes, a delay longer then the length of 1 byte is better still, as it allows perfect resync to the next byte even if there was a massive fault in the previous byte like electrical noise or a bad wiring connection etc.