Baud rate in Device Manager vs datasheet

[bodzio_stawski]

Hello

I have watched review of a converter based on chip CH340/341.



It's very popular model on chinese auctions.

I discovered something strange after I read a datasheet.

http://www.anok.ceti.pl/download/ch341ds1.pdf

...on page number 9:

"The following communication band rates are supported by CH341:
50,75,100,110,134.5,150,300,600,900,1200,1800,2400,3600,4800,9600,14400,19200,28800,33600,38400,
56000,57600,76800,115200,28000,53600,30400,60800,21600,500000,2000000 and so on".

Then I come back to the video and in 3:30 I see that in Device Manager the maximum baud rate/bitrate is 128000. Why so low? have any of you used such a converter and can determine why the driver of this device shows such a cautiously low maximum value in device manager? Btw. "and so on" sounds strange for me too. And more strange values ​​(or just the first digits being lost) in the numbers which ​​I bold.

Regards

[pcprogrammer]

Probably a software versus hardware thing. But indeed the "so on" is a bit weird.

I'm not familiar with Windows anymore, but in the old days 115200 was about the maximum one could get.

Many microcontrollers of today can do megabits on the UARTS and this is where the CH340/341 series are used a lot. Guess that it just depends on the driver what it supports.

[ledtester]

According to this page:

https://github.com/nospam2000/ch341-baudrate-calculation

the CH341 has two customizable parameters to generate the baud clock:

baudrate = 12 MHz / prescalar / divisor

where prescalar is either 1, 2, 8, 16, 64, 128, 512, 1024 and divisor is any number between 2 and 256.

From the github page:

Using this formula together with choosing the right prescaler will give you an relative baud rate error <= 0.16% for the common baud rates. For all other baud rates between 46 to 100000 (the uncommon ones) the error is < 0.8% . Above 100000 baud you should only use selected baud rates.

The algorithm in python:

Code: [Select]

prescalers = [ 1, 2, 8, 16, 64, 128, 512, 1024]

FCLK = 12_000_000

def find_baud(baud):
    for pre in prescalers:
        div = int(2*FCLK/(pre*baud+1)/2)
        if (pre == 1) and (div <= 8):
            continue;
        if (div <= 256) and (div >= 2):
            b = FCLK/pre/div
            err = (b/baud)-1
            return {"prescaler": pre, "divisor": div, "error": err, "actual_baud": b}
    return None
   
print(find_baud(21600))

For 21600, the results are:

{'prescaler': 8, 'divisor': 69, 'error': 0.006441223832528209, 'actual_baud': 21739.130434782608}

[bodzio_stawski]

Hm... But let's say: prescaler = 1 and divisor = 2 and we get baudrate = 6 Mb/s from this?

[radiolistener]

Device manager shows standard speeds in the list, but the driver allows to use non standard speed.

There are two issues with serial port speed:
1) Crystal quartz frequency is not precise and can shift from temperature change
2) Divider and frequency allows to get speed with some error

Both means that there is some speed error, at higher speed these error are more critical and leads to more communication errors.

[srb1954]

Device manager shows standard speeds in the list, but the driver allows to use non standard speed.

There are two issues with serial port speed:
1) Crystal quartz frequency is not precise and can shift from temperature change
2) Divider and frequency allows to get speed with some error

Both means that there is some speed error, at higher speed these error are more critical and leads to more communication errors.

The temperature drift from a normal crystal oscillator is negligible for UART operation and quite often you can get away with a lesser quality oscillator such as one based on a ceramic resonator or even a 555. A standard UART can typically function correctly with up to 5% frequency error from the nominal providing the incoming signal is clean and doesn't have any bias distortion or jitter.

Baud rate generators that divide down from a high frequency clock using integer dividers will always have some error in the generate baud rate unless the baud rate is an exact integer sub-multiple of the clock frequency. This error tends to get larger and larger as the baud rate increases closer to the master clock frequency.

[radiolistener]

The temperature drift from a normal crystal oscillator is negligible for UART operation and quite often you can get away with a lesser quality oscillator such as one based on a ceramic resonator or even a 555.

No, I've found that at 10 Mbps speed MEMS-resonator (from Microchip) frequency drift prevents stable communication.

[ledtester]

Hm... But let's say: prescaler = 1 and divisor = 2 and we get baudrate = 6 Mb/s from this?

The github page says the maximum officially supported baudrate is 2M baud.

Also, it says here:

https://github.com/nospam2000/ch341-baudrate-calculation#stop-bit-length-too-long-for-baud-rates--500000

that the minimum duration of the stop bit is 2 microseconds. This means that for baud rates greater than 500k baud the stop bit will be longer than expected and will effectively slow down the data transfer rate.

[srb1954]

Hm... But let's say: prescaler = 1 and divisor = 2 and we get baudrate = 6 Mb/s from this?

Probably only in synchronous mode although the data sheets suggest a maximum of 2Mb/s so it may be restricted by other timing factors.

In asynchronous mode UARTs generally use an internal clock at 16x the desired baud rate so the maximum baud rate you could achieve from a 12MHZ clock would be 12,000,000/16/2 = 375,000 baud unless the chip has an internal PLL to multiply up the 12MHz clock.

[DavidAlfa]

Actually you can adjust the baudrate a lot finer than standard steps, ex. recently I had to use 120.000 baud for a weird board which was a bit off, worked great, at 115.200 I was getting a lot of corruption, checked the timing with the scope and that was it!

[srb1954]

The temperature drift from a normal crystal oscillator is negligible for UART operation and quite often you can get away with a lesser quality oscillator such as one based on a ceramic resonator or even a 555.

No, I've found that at 10 Mbps speed MEMS-resonator (from Microchip) frequency drift prevents stable communication.

If you are using a UART I would suggest that you have some other factor than just clock frequency stability that is causing your errors. As stated a standard UART will definitely tolerate a significant frequency error, much greater than you would ever expect from a MEMs oscillator.

However, if you have a USART and are using it in synchronous mode which is more plausible at the 10Mbps data rate, then you will definitely see errors over the longer term unless the baud clock is exactly locked to the baud rate of the incoming signal using a clock recovery circuit. Even using a super stable clock derived from a rubidium oscillator or similar would not be enough to guarantee zero errors over the longer term in a synchronous communication system.

[David Hess]

I'm not familiar with Windows anymore, but in the old days 115200 was about the maximum one could get.

Even in the old days higher baud rates were supported but many UARTs, but RS-232 compliant transceivers were usually limited to 115.2k and slower.  Some RS-232 transceivers would only work up to 19.2k, but RS-422, RS-485, or logic levels over short distances could operate much faster than 115.2k.

[coromonadalix]

I use some Dwin HMI displays, and they run at 921600 bauds   

Only ftdi chips where reliable for me ...

[magic]

For UART to work reliably the bitrate must be several times less than the clock rate of the receiver, so that incoming waveform can be oversampled to deal with clock skew and jitter of the transmitter and any other variation due to board parasitics, finite slew rate, etc.

10Mb/s is rather unusual, although some chips like FT2232H and PL2303HXD can go to 12Mb/s thanks to fast internal clocks.

Cheap USB UARTs often top out at 3Mb/s for whatever reason; that should be 1/16 of their internal clock because it seems common for Full Speed USB devices to run at 48MHz.

[David Hess]

For UART to work reliably the bitrate must be several times less than the clock rate of the receiver, so that incoming waveform can be oversampled to deal with clock skew and jitter of the transmitter and any other variation due to board parasitics, finite slew rate, etc.

10Mb/s is rather unusual, although some chips like FT2232H and PL2303HXD can go to 12Mb/s thanks to fast internal clocks.

Cheap USB UARTs often top out at 3Mb/s for whatever reason; that should be 1/16 of their internal clock because it seems common for Full Speed USB devices to run at 48MHz.

A commonly used improvement is to sample multiple times during the bit duration and accept the majority, but this also requires the sampling strobe to be a multiple of the baud rate.