Siemens 7 - Manual (Page 13)

Multiplexer Driver Developer’s Guide
2.2 Handling of the Physical Serial Port
s
Mux_Drv_DevGuide_v07 Page 13 of 36 2006-9-27
Confidential / Released
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.2 Handling 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.
2.3 Module Detection
The module supports an auto-baud mode and constant baud rates. Furthermore, the module can stay in “normal
AT command mode” or in WinMux2k mode. To establish a communication to the module the correct baud rate
and the state of the module must be found. Therefore it is recommended to set the module into auto baud mode.
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.
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