[fpc-pascal] Serial unit for Linux and Windows

[Stephano]

Marco van de Voort wrote:
> 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
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.

>> 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
Agreed!

>> 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
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.