Hello all,

I'm trying to figure out wat the allowable baudrates are for my serial
ports: one build-in RS232, one CP2102 USB-to-serial.

The problem is that none of places I've been looking gives me the full
scope. Worse, two of them give me nonsense.

1) When going thru the "device manager" and looking at the "Port settings" I get, for both seral ports, the same "Bits per second" dropdown list, from 75
to 128K.

The thing is that the RS232 port doesn't want to accept 128K, and the CP2120 doesn't do anything below 300. Also, the latter has 8 baudrates above 128K, which are not shown.

Also, for some reason the "Data bits" dropdown shows "4" as possibility,
which I've never seen mentioned anywhere.

2) When I (in a program) call the Kernel32.dll "CommConfigDialog" the "COM1" RS232 port doesn't show 128k, but does show three speeds above it. Neither 128K nor the three other speeds are accepted.

3) When I (in a program) call the kernel32.dll "GetCommProperties" I only
get baudrates upto 128K (as marked by their bitflags in the COMMPROP structure), meaning that I do not get the eight baudrates above 128K which CP1202 supports.

tl;dr:

I have three sources by which I can ask the OS about the capabilities of a serial port, and none of them agrees with the other. And the one non-interactive method (GetCommProperties) only returns a subset of the available baudrates.

My question:

How do I (programmatically) retrieve all the baudrates for a serial port (native, USB or otherwise) ?

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

... man, I wrote "CP2102" wrong not once, but twice. :-(

Once as "CP2120" and once as "CP1202". Sorry for the (eventual) confusion.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 5 Oct 2023 10:11:28 +0200, R.Wieser wrote:

How do I (programmatically) retrieve all the baudrates for a serial port (native, USB or otherwise) ?

Not possible, since the serial port controller doesn't store such
information in the first place. See RBIL's port list.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

JJ,

How do I (programmatically) retrieve all the baudrates for a serial port
(native, USB or otherwise) ?

Not possible, since the serial port controller doesn't store such
information in the first place. See RBIL's port list.

:-) This time my question is Windows related, not DOS.

But if thats so, where does "GetCommProperties" get its permissable
baudrates data from ? Mind you, that "dwSettableBaud" bitmask returns different results for both ports (AFAIKS correctly so for the CP2102).
Where does that bitmask come from ?. Besides, if it can't why does it exist
to begin with ?

Also, the CP2102 isn't a UART, but a microcontroller acting as a bridge
between an USB port and a few serial lines. It also needs to have some
device driver software installed to be able to use it. IOW, /both/ could contain the list I'm looking for.

Don't get me wrong: I can imagine that there might be reasons why they never put such a shortlist in either the microcontroller or the device driver.
But if the list exists I want to know how to get at it, or get an
explanation to why its (still) not implemented (its existence sounds like a no-brainer to me...). I mean, its not 1987 anymore (the date of the 16550 UART). :-)

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 6 Oct 2023 15:05:32 +0200, R.Wieser wrote:

:-) This time my question is Windows related, not DOS.

Hardware ports are platform independent.

But if thats so, where does "GetCommProperties" get its permissable
baudrates data from ? Mind you, that "dwSettableBaud" bitmask returns different results for both ports (AFAIKS correctly so for the CP2102).
Where does that bitmask come from ?.

Device drivers for standard serial port controllers brute force the clock divisor configuration in order to detect the acceptable baud rates against standard baud rates.

USB based serial port controllers don't use standard serial port
controllers. They use custom one made to work like serial port controller,
but with different pinouts, and thus different method of usage. Device
drivers for it are usually designed for specific chip model, and hardcode
the speed list instead of querying the chip. That saves time and money for
the device driver development.

Besides, if it can't why does it exist to begin with ?

It's for backward compatibility with older peripheral devices. Some can't handle more than 9600 or 19200 bauds. Some can only handle one specific
speed, because it's cheaper to make the chip or use cheaper chip.

Also, the CP2102 isn't a UART, but a microcontroller acting as a bridge between an USB port and a few serial lines. It also needs to have some device driver software installed to be able to use it. IOW, /both/ could contain the list I'm looking for.

Yes, USB based serial port controllers could. But it won't be part of either Windows API or the serial port standards. Everything will have to be implemented as vendor-specific. e.g. custom IOCTLs. You'll have to find out
the exact chip model number/code, and hope that the manufacturer provides a user manual for it. FYI, almost all don't.

Don't get me wrong: I can imagine that there might be reasons why they never put such a shortlist in either the microcontroller or the device driver.
But if the list exists I want to know how to get at it, or get an
explanation to why its (still) not implemented (its existence sounds like a no-brainer to me...). I mean, its not 1987 anymore (the date of the 16550 UART). :-)

Serial port is part of the old ISA-era PC components. There's no Plug 'n
Play yet in that PC era. PnP is still too expensive to make. Most peripheral devices and components aren't smart yet. Most of their functionalities are hardwired in the chip's logic gates. Chips with built in memory were still expensive to make.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

JJ,

Hardware ports are platform independent.

Indeed.

So, how do I get that baudrate bitmask onder DOS ? the RBIL doesn't mention it, even though I can easily get it under Windows. :-P

Also, most of those hardware ports seem to need device drivers, which is ofcourse software and as such again platform specific.

IOW, for my question the targetted platform does seem to matter.

Device drivers for standard serial port controllers brute force the
clock divisor configuration in order to detect the acceptable baud
rates against standard baud rates.

Possible, but I've got no information supporting it.

The thing is that above 128K there do not seem to be any "standard
baudrates". Just do a Google for them and see what you (not) get ... :-(

I did find a list with some 128k+ baudrates. It shows four in the 128K+ ... 921600 range, where the CP2102 hardware docs shows eight. :-\

And it gets even "funnier" when you would take a look at the newer CP2104,
as that thing goes upto 2Mbps, and I've seen ones going upto 3Mbps. As of
yet I've still have to encounter a list with standard baudrates above 921600 bps ...

Yes, USB based serial port controllers could. But it won't be part of
either Windows API or the serial port standards. Everything will have
to be implemented as vendor-specific. e.g. custom IOCTLs.

Pray tell, how do you know it would need to be a *custom* IOCTL ?

Also, if you have a list of standard IOCTLs for serial devices I sure would like to have a copy of it, as my search for "NTIoControlDeviceFile 1B0074"
(as executed by GetCommProperties) doesn't even return anything in regard to that specific commandcode.

Having names for the different command codes would make my current disassembling of the CP2102's "silabser.sys" device driver (and recognising
the function of each part) a lot easier.

But yes, thats pretty-much what I'm after: A way to ask the device-driver / microcontroller what its extended capablilities are. Just like NTIoControlDeviceFile with the commandcode 0x1B0074 does for its basic capabilities (yes, I took a peek into the GetCommProperties functions code).

Serial port is part of the old ISA-era PC components. There's no Plug
'n Play yet in that PC era.

From my POV thats not a problem. Just ask the device-driver/hardware if it
has extended capabilities, and if it responds with an "unknow request" error
it doesn't have any. Simples. :-)

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 7 Oct 2023 14:39:32 +0200, R.Wieser wrote:

JJ,

Hardware ports are platform independent.

Indeed.

So, how do I get that baudrate bitmask onder DOS ? the RBIL doesn't mention it, even though I can easily get it under Windows. :-P

Also, most of those hardware ports seem to need device drivers, which is ofcourse software and as such again platform specific.

IOW, for my question the targetted platform does seem to matter.

Device drivers for standard serial port controllers brute force the
clock divisor configuration in order to detect the acceptable baud
rates against standard baud rates.

Possible, but I've got no information supporting it.

The thing is that above 128K there do not seem to be any "standard baudrates". Just do a Google for them and see what you (not) get ... :-(

I did find a list with some 128k+ baudrates. It shows four in the 128K+ ... 921600 range, where the CP2102 hardware docs shows eight. :-\

And it gets even "funnier" when you would take a look at the newer CP2104,
as that thing goes upto 2Mbps, and I've seen ones going upto 3Mbps. As of yet I've still have to encounter a list with standard baudrates above 921600 bps ...

Yes, USB based serial port controllers could. But it won't be part of
either Windows API or the serial port standards. Everything will have
to be implemented as vendor-specific. e.g. custom IOCTLs.

Pray tell, how do you know it would need to be a *custom* IOCTL ?

Also, if you have a list of standard IOCTLs for serial devices I sure would like to have a copy of it, as my search for "NTIoControlDeviceFile 1B0074" (as executed by GetCommProperties) doesn't even return anything in regard to that specific commandcode.

Having names for the different command codes would make my current disassembling of the CP2102's "silabser.sys" device driver (and recognising the function of each part) a lot easier.

But yes, thats pretty-much what I'm after: A way to ask the device-driver / microcontroller what its extended capablilities are. Just like NTIoControlDeviceFile with the commandcode 0x1B0074 does for its basic capabilities (yes, I took a peek into the GetCommProperties functions code).

Serial port is part of the old ISA-era PC components. There's no Plug
'n Play yet in that PC era.

From my POV thats not a problem. Just ask the device-driver/hardware if it has extended capabilities, and if it responds with an "unknow request" error it doesn't have any. Simples. :-)

Regards,
Rudy Wieser

Bottom line is, what you're looking for is vendor-specific. Windows API
doesn't directly provide it. Even if you find a solution for your CP2102 USB-to-serial device, it may not applicable for other USB-to-serial devices such as CH340.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

JJ,

Bottom line is, what you're looking for is vendor-specific

With all due respect, but how do you know that its vendor specific ? Do
you have info you have not mentioned yet ?

Windows API doesn't directly provide it.

I've not been able to find an API call for it either. But that I have not found it does not prove in any way that it doesn't exist. Hence my
question.

And no, I've not been able to find any XP(!) Windows API support myself. But
as XP as way older than the CP2102 it rather possible that such a IoCtrl command was added after I got my copy of the OS.

Which just means that I, if such an IoCtrl code has been added (and become mainstream since than), would need to execute an "NTIoControlDeviceFile"
call myself. Not something I regard as problematic.


The bottom line to me is that you have no information of anything like it existing, and are concluding that it /thus/ (if it exists) must be a vendor-specific.

I'm afraid that that doesn't quite work for me. You could be absolutily right, but as you haven't brought anything forward to support it with I
can't take it as an answer. Sorry.

I'll just do some more disassembling and googeling I guess. :-)

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

JJ,

I've disassembled the silabser.sys device drive far enough to be able to
find the code handling the IoCtrl requests. It helped that the driver also converted such request codes into strings for debugging purposes*, making it
so much easier to figure out which request was what. :-)

* but seem to have changed the actual Debug Output code into just a RET ...

I did not see any IOCTL_SERIAL_* request which could be related to a list baudrates, neither did any of the vendor-specific Cp210x_* requests turn anything up.

IOW, I'm out of luck and you happened to be right, and its not available



Now thats answered I've got something else I do not get, at all : GetCommProperties returns a COMMPROP structure containing a dwMaxBaud field.

https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-commprop

All three serial ports (over two 'puters) I've checked show 0x10000000.

I don't think that that translates to 268435456 baud, but if I consider it
to be a bitflag it doesn't make much sense either : there can be only a
single maximum baudrate, so why use a bitflag ?

Also, the above value (bitflag) translates to BAUD_USER, which tells me absolutily nothing. Other perhaps than that its not one of the common baudrates mentioned in the table - but than they could just have used 0x0.

IOW, do you have any idea why they used a saying-nothing bitflag there
instead of just a straight-forward value ?

Yeah, I know thats asking for something that possibly unanswerable. Its
just that it bothers me to see such non-informational data being returned.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 11 Oct 2023 10:29:29 +0200, R.Wieser wrote:

JJ,

I've disassembled the silabser.sys device drive far enough to be able to
find the code handling the IoCtrl requests. It helped that the driver also converted such request codes into strings for debugging purposes*, making it so much easier to figure out which request was what. :-)

* but seem to have changed the actual Debug Output code into just a RET ...

I did not see any IOCTL_SERIAL_* request which could be related to a list baudrates, neither did any of the vendor-specific Cp210x_* requests turn anything up.

IOW, I'm out of luck and you happened to be right, and its not available

It's not a coincidence. It's based on experience. Try getting a different USB-to-serial device. There's a high chance that the case would be the same.

Now thats answered I've got something else I do not get, at all : GetCommProperties returns a COMMPROP structure containing a dwMaxBaud field.

https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-commprop

All three serial ports (over two 'puters) I've checked show 0x10000000.

I don't think that that translates to 268435456 baud, but if I consider it
to be a bitflag it doesn't make much sense either : there can be only a single maximum baudrate, so why use a bitflag ?

Also, the above value (bitflag) translates to BAUD_USER, which tells me absolutily nothing. Other perhaps than that its not one of the common baudrates mentioned in the table - but than they could just have used 0x0.

IOW, do you have any idea why they used a saying-nothing bitflag there instead of just a straight-forward value ?

Yeah, I know thats asking for something that possibly unanswerable. Its
just that it bothers me to see such non-informational data being returned.

It roughly means: user specified. IOTW: any.

But no device has no limit. It has to have a limit. At least for this
specific case. Thus it means: unspecified. IOTW: unknown.

In short, it tells us everything, which is: nothing.

There's no guarantee that a device provides the information via
vendor-specific method. Or a way to tell whether it provides any, programmatically.

As long as the standard specification doesn't say so, you shouldn't expect
or insist something to exist.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

JJ,

It's not a coincidence. It's based on experience.

I would have liked to have read that.

Pardon me, but I've had to many people tell me stuff as if they where facts, only to later discover that their "facts" where conjured outof thin air (had
no basis). Documentation still trumps experience, but I will take the
latter as a strong signal (probably won't stop me from what I already did to verify it though... :-) )

Try getting a different USB-to-serial device. There's a high chance
that the case would be the same.

Seeing that I cannot find any IOCTL_SERIAL_* which will do it, and the
CP210x 0x222??? IoControl codes can mean something quite different for
another device (if they than mean anything at all to begin with) I cannot
other than agree with your "high chance" there.

Alas, it means that I can't create an up-to-the-times serial connection configuration dialog (making it easy to select fast baudrate *that will be accepted* by the targetted serial device). :-\

It roughly means: user specified. IOTW: any.

But no device has no limit. It has to have a limit. At least for
this specific case. Thus it means: unspecified. IOTW: unknown.

Not specifying would be easy, just don't set any bitflag (leave the field
0x0).

But now it *is* specified, though neither of us can figure out *what* is specified. If we assume its indicating BAUD_USER its, in the "maximum
accepted baudrate" context, absolutily meaningless. :-\

There's no guarantee that a device provides the information via vendor-specific method.

The IOCTL_SERIAL_GET_PROPERTIES request isn't what I would call "vendor specific" ...

The problem with the returned dwMaxBaud field is that not even the MS documentation says anything about that 0x10000000 (BAUD_USER ?) value, let alone usefull to it. :-\

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)