From: jj4public@outlook.com   
      
   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: you cannot sedate... all the things you hate (1:229/2)