I am planning to improve, if possible, the serial units for both Linux and Windows, but have a few questions before I proceed any further:

1- I guess the unit rtl\win\wininc\struct.inc has 2 bugs: a- bm_DCB_fRtsControl = $3000. It should be $2000. b- bm_DCB_fDtrControl = $30. It should be $20.
Can anybody confirm this?

2- I will define TSerialFlags = set of (XOnXOffFlowControl, RtsCtsFlowControl);
What flags do we have to set in Linux to have XOnXOff handshaking? The number of parameters in tios is mind boggling.

3- The Linux SerOpen function (based on fpopen) claims to return 0 if the device could not be found. Shouldn't it be -1?

4- Windows SerOpen function (based on CreateFile) returns an INVALID_HANDLE_VALUE if the device could not be found. How to unify for both Linux & Windows? Is it safe to return instead -1 (as in the Linux case)?

5- Is it OK to designate serial ports by COMx fow Windows and /dev/ttySx for Linux?

6- Is it OK for TSerialState to include DCB for Windows and tios for Linux?

My guess for questions 5 and 6 is yes.

Any input is appreciated.

Stephano

On Thu, April 10, 2008 01:11, Stephano wrote:
.
.

4- Windows SerOpen function (based on CreateFile) returns an INVALID_HANDLE_VALUE if the device could not be found. How to unify for both Linux & Windows? Is it safe to return instead -1 (as in the Linux case)?

.
.

If I read the Windows unit sources correctly, INVALID_HANDLE_VALUE = -1 too. However, I believe that you might consider returning UnusedHandle constant defined in System unit for all the platforms (that's -1 for at least most of them anyway, but I believe that it may be still better from portability point of view to refer to it using this constant).

Tomas

No, they are correct. If you look into the headers you'll see:

DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB;

Note the :2 with frts and fdtr. These are two bit values, not one bit, so a mask that masks 2 bits makes sense

2- I will define TSerialFlags = set of (XOnXOffFlowControl, RtsCtsFlowControl); What flags do we have to set in Linux to have XOnXOff handshaking? The number of parameters in tios is mind boggling.

Well the existance of flags are named "IXON", "IXOFF" and "IXANY" might provide a clue when googled.

3- The Linux SerOpen function (based on fpopen) claims to return 0 if the device could not be found. Shouldn't it be -1?

Probably. In 1.0.x times FPC unix functions had own error conventions.

4- Windows SerOpen function (based on CreateFile) returns an INVALID_HANDLE_VALUE if the device could not be found. How to unify for both Linux & Windows? Is it safe to return instead -1 (as in the Linux case)?

See Tomas, it is define

5- Is it OK to designate serial ports by COMx fow Windows and /dev/ttySx for Linux?

No, since e.g a serial port on some other device might have a different state. And strictly, this is even possible for Windows. Always keep naming configurable and overridable. Those series are extremely common, but not that

Also note that serial.pp is a general unix unit, not just linux. So it needs to work on FreeBSD too. (and maybe Mac, but I have no serial on my mac anymore)

I've acquired a serial device suitable for testing with FreeBSD if needed.

6- Is it OK for TSerialState to include DCB for Windows and tios for Linux?

I don't understand what you mean with this.

I cannot rely on what the actual value of INVALID_HANDLE_VALUE really is as it could in theory change. But nevertheless your suggestion to return the UnusedHandle constant, once I locate it :), is very logical.

Stephano wrote

I am planning to improve, if possible, the serial units for both Linux and Windows, but have a few questions before I proceed any further:

...

5- Is it OK to designate serial ports by COMx fow Windows and /dev/ttySx for Linux?

FWIW, I have a USB to serial converter. It shows as /dev/ttyUSB0.

Regards,
Koenraad Lelong.

They are 2 bit values indeed, but each value has a specific function. fDtrControl can be: DTR_CONTROL_DISABLE, DTR_CONTROL_ENABLE, or DTR_CONTROL_HANDSHAKE. The latter is the common DTR/DSR handshaking choice. fRtsControl can be: RTS_CONTROL_DISABLE, RTS_CONTROL_ENABLE, RTS_CONTROL_HANDSHAKE, or RTS_CONTROL_TOGGLE. RTS_CONTROL_HANDSHAKE is the normal choice for a RTS/CTS handshaking.
This is what dictated my suggestion for the values of $2000 and $20.

Well the existance of flags are named "IXON", "IXOFF" and "IXANY" might provide a clue when googled.

MAN Stty will give much better results than google for these parameters. I had tried a few months ago to have a XOn/XOff serial communication, but I failed somewhere. I tried to use the flags you describe, but without success unfortunately. Could be something wrong with my hardware setup though. I will retry eventually again.

> 3- The Linux SerOpen function (based on fpopen) claims to return 0 if > the device could not be found. Shouldn't it be -1? Probably. In 1.0.x times FPC unix functions had own error conventions.

I will change it then to -1.

Agreed!

I think you might have misunderstood me. I am in fact saying that we should not standardize between Unix ;) and Windows for port names, just for the reasons you mentioned. Pls correct me if I am wrong.

Also note that serial.pp is a general unix unit, not just linux. So it needs to work on FreeBSD too. (and maybe Mac, but I have no serial on my mac anymore)

I will not change the basic Unix unit except for minor modifications if needed.

I've acquired a serial device suitable for testing with FreeBSD if needed.

I have serial devices for testing. You can still test the finished work with FreeBSD if you like.

> 6- Is it OK for TSerialState to include DCB for Windows and tios for Linux? I don't understand what you mean with this.

The TSerialState for Windows is defined as:
LineState: integer or so
DCB: TDCB
for Unix, it is:
LineState: ssame
tios: termios structure
I do not think there is a way to unify this.

Koenraad Lelong wrote

> 5- Is it OK to designate serial ports by COMx fow Windows and /dev/ttySx > for Linux? FWIW, I have a USB to serial converter. It shows as /dev/ttyUSB0.

I see now how I did not express myself clearly: I meant that I did not intend to change the way devices are specified. Under Unix, you will be able to (and will have to) specify /dev/ttyUSB0 or any valid devicename to open.

Do I understand correctly that you cannot find it? As I wrote above, this constant is defined in unit System, i.e. always available without any additions to the uses clause or so.

Tomas

Tomas Hajny wrote

Do I understand correctly that you cannot find it? As I wrote above, this constant is defined in unit System, i.e. always available without any additions to the uses clause or so.

I was just too lazy to launch Lazarus/FPC and look for it when I replied. As you mention, it is readily available.