Serial unit for Linux and Windows

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Serial unit for Linux and Windows

Stephano-2
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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Serial unit for Linux and Windows

Tomas Hajny
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


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Serial unit for Linux and Windows

Marco van de Voort
In reply to this post by Stephano-2
> 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?

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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Serial unit for Linux and Windows

Jeff Wormsley

Marco van de Voort wrote:
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 
  
While not exactly the same situation, for one of my Windows apps in Delphi, I had to support real serial ports, virtual serial ports, and PC/SC card readers.  I found it easier to present a string list of all devices and allow the user to select from the string list the port/device needed.  Something similar can probably be done here, where the Windows ports can be read from the registry (a tricky process when virtual ports are involved such as com redirection over tcp/ip) and *nix can read the /dev/ttyS* entries.  Then port selection is simply passing in the string selected from the string list.  Completely Delphi incompatible, but probably the only way to get truly cross platform.  You can't just assume a 1 is COM1 on Windows and /dev/ttyS1 on *nix.  Windows can name ports "Virtual COM1" instead of "COM1" and then your attempt at passing '1' to build 'COM1' won't work.  Likewise, on Linux, you might have /dev/modem for a serial port (in theory anyway, not sure if you'd access that as just a serial port).  Of course, this just makes building the list the hard part.

Jeff.
--
I haven't smoked for 1 year, 7 months and 3 weeks, saving $2,716.59 and not smoking 18,110.61 cigarettes.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Serial unit for Linux and Windows

Stephano-2
In reply to this post by Tomas Hajny
Tomas Hajny wrote:
> 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).
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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Serial unit for Linux and Windows

Koenraad Lelong-2
In reply to this post by Stephano-2
Stephano schreef:
> 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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Serial unit for Linux and Windows

Stephano-2
In reply to this post by Marco van de Voort
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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Serial unit for Linux and Windows

Stephano-2
In reply to this post by Koenraad Lelong-2
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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Serial unit for Linux and Windows

Tomas Hajny
In reply to this post by Stephano-2
On Fri, April 11, 2008 22:12, Stephano wrote:

> Tomas Hajny wrote:
>> 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).
> 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.

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


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Serial unit for Linux and Windows

Stephano-2
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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal