Multiplexer Driver Developer’s Guide
2.2 Handling of the Physical Serial Port
s
Figure 1 shows the driver architecture of winmux2k.sys in the operating system. The device driver winmux2k.sys emulates virtual serial ports. The lower layer of the WinMux2k driver is the physical serial port driver (serial.sys). The WinMux2k driver is loaded during system startup. It creates virtual port objects. The physical port is opened, when the first virtual port is opened by an application.
If the last virtual port is closed the physical port will be released by the WinMux2k driver. This allows applications to access the module without the WinMux2k driver.
If the WinMux2k driver is opened by at least one application a special device object is attached to the driver stack of the serial.sys driver. This device object is used to control the power management request. It is detached from the stack if the last handle is closed.
2.2Handling of the Physical Serial Port
When the physical port is opened, the WinMux2k driver initializes it. During the initialization the physical port is set to hardware handshake. This means the RTS and CTS signals on the port side are controlled by the hardware and the WinMux2k device driver. The DTR signal is set to 1. The port mode is set to 8 bits, 1 stop bit, no parity. The baud rate can be configured using the winmux2k.inf file or the Serial Multiplexer property page. If fast baud rates are selected (e.g. 115200 bps) the receive FIFO of the UART should be configured for a size of 8 bytes. This can be done using the property page of the COM Port in the device manager.
Table 1: Physical serial port
Signal | Description |
|
|
RTS/CTS | Hardware controlled |
|
|
DTR | Set to 1 |
|
|
Baud rate | Variable, parameter read from registry |
|
|
Data bits | 8 |
|
|
Parity | No |
|
|
Stop bits | 1 |
|
|
2.3Module Detection
The module supports an
If the baud rate is programmed to a constant value, the driver has to find the correct baud rate. To do so, the driver sends an “AT” command to the module, trying different baud rates until the correct one is found. If the mod- ule doesn’t answer to the initial “AT” sent at the first baud rate, the driver tries to disable the possibly enabled multiplexer mode. This is done because the module might still be kept in multiplexer mode due to an earlier fail- ure. If this fails, the driver sends again the initial “AT” command using the next baud rate from the list of supported baud rates. The driver must wait for a given timeout before the decision can be made that the module does not answer at any baud rate. The timeout value can be changed in the Windows Registry (see “RequestTimeout” value in Table 6). It can take some time before the driver finds the correct baud rate or before the driver fails to call the Open() function. Even if the module is not connected to the serial port or is turned off, the long timeout period occurs.
If the connection to the module has been established the baud rate set in the Registry is used for further com- munications.
Closing the last port deactivates the multiplexer mode and causes the module to return to “normal AT command mode” without multiplexer. Also, autobauding (AT+IPR=0) will be enabled once again. Finally, the AT^SMSO command will be sent to switch the module off. Only in the case of TC45 and XC18, AT^SMSO will not be sent. Instead, TC45 and XC18 remain in “normal AT command mode” and can be quickly accessed from the PC debug environment.
Mux_Drv_DevGuide_v07 | Page 13 of 36 | |
Confidential / Released |
|
|