.Mode Property


Sets operating mode for the currently selected serial port (selection is made through ser.num).


Enum (pl_ser_mode, byte)

Value Range:

0- PL_SER_MODE_UART (default): UART mode.

1- PL_SER_MODE_WIEGAND: Wiegand mode.

2- PL_SER_MODE_CLOCKDATA: clock/data (magstripe interface) mode.

See Also:

Three Modes of the Serial Port, Serial Settings


Follows is a short introduction of three operating modes of the serial port:

UART modeSuitable for RS232, RS422, RS485, etc. communications in full-duplex or half-duplex mode (see ser.interface). Data is transmitted through the TX pin and received through the RX pin. Optionally, RTS (output) and CTS (input) lines are used for flow control (see ser.flowcontrol) in the full-duplex mode. Additionally, RTS can be used for direction control in the half-duplex mode.
Wiegand modeSuitable for sending to or receiving data from any standard Wiegand device. Data  transmission is through pins W0out and W1out, reception- through W0&1in and W1in. "W0&1in" means that a logical AND of W0 and W1 signals must be applied to this input. Therefore, external logical gate is needed in order to receive Wiegand data.
Clock/data modeSuitable for sending to or receiving data from any standard clock/data (or magstripe) device. Data transmission is through pins cout and dout, reception- through cin and din. Third line of the magstripe interface- card present- is not required for data reception. For transmission, any I/O line can be used as card present output (under software control).

Changing port mode is only possible when the port is closed (ser.enabled= 0- NO). Depending on your platform, you may be allowed to remap RTS/W1out/cout and CTS/W0&1in/cin lines to other I/O pins of the device through the ser.rtsmap and ser.ctsmap properties. Also, depending on selected mode and your platform you may be required to configure some or all of your serial port's lines as inputs or outputs through the io.enabled property of the io object. For more information, refer to your device's platform documentation (for example, EM1000's is here).


We understand that it would be much more logical to call this property "interface", not "mode". Problem is, this property was added later, when ser.interface already came to mean something else. So, we had no choice but to choose unused term.