(Unix) serial port handling

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

(Unix) serial port handling

Mark Morgan Lloyd-5
Can anybody say whether there is a good reason that serial.pp lacks a
function to read the CD signal?

Is SerFlush, which calls fpfsync, intended to discard input data, output
data or both?

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: (Unix) serial port handling

greim
Hi Mark,

> Can anybody say whether there is a good reason that serial.pp lacks a
> function to read the CD signal?
>
i would recommend the synaser library, more sophisticated then the serial.pp

http://www.ararat.cz/synapse/doku.php/download

there is a function getCarrier, i guess this is what you need.

If you are working on a ARM system you have to modify some lines in
synaser. Please check my previous messages.

> Is SerFlush, which calls fpfsync, intended to discard input data, output
> data or both?
>
don't know in serial.pp

In synaser AFAIK on Linux only the transmit buffers,  on Windows RX and TX



Mit freundlichen Grüßen

Markus Greim

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

Re: (Unix) serial port handling

Mark Morgan Lloyd-5
greim wrote:
> Hi Mark,
>
>> Can anybody say whether there is a good reason that serial.pp lacks a
>> function to read the CD signal?
>>
> i would recommend the synaser library, more sophisticated then the
> serial.pp
>
> http://www.ararat.cz/synapse/doku.php/download

I know you would. There are cases where it is not appropriate, for
example when one needs to enqueue no only the received character but
also a timestamp plus the instantaneous values of the control signals.

> there is a function getCarrier, i guess this is what you need.
>
> If you are working on a ARM system you have to modify some lines in
> synaser. Please check my previous messages.

Thanks, noted.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: (Unix) serial port handling

Henry Vermaak
In reply to this post by Mark Morgan Lloyd-5
On 08/03/11 10:30, Mark Morgan Lloyd wrote:
> Can anybody say whether there is a good reason that serial.pp lacks a
> function to read the CD signal?
>
> Is SerFlush, which calls fpfsync, intended to discard input data, output
> data or both?

fsync just makes sure all the in-kernel caches are written to the
device.  Flushing input data is just a matter of reading it.

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

Re: (Unix) serial port handling

Mark Morgan Lloyd-5
Henry Vermaak wrote:
> On 08/03/11 10:30, Mark Morgan Lloyd wrote:
>> Can anybody say whether there is a good reason that serial.pp lacks a
>> function to read the CD signal?
>>
>> Is SerFlush, which calls fpfsync, intended to discard input data, output
>> data or both?
>
> fsync just makes sure all the in-kernel caches are written to the
> device.  Flushing input data is just a matter of reading it.

Thanks for that Henry. Obviously there's scope for confusion here with
the kernel's tcflush() and tcdrain() functions, where tcflush discards
input and/or output data.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: (Unix) serial port handling

Marco van de Voort
In our previous episode, Mark Morgan Lloyd said:
> > fsync just makes sure all the in-kernel caches are written to the
> > device.  Flushing input data is just a matter of reading it.
>
> Thanks for that Henry. Obviously there's scope for confusion here with
> the kernel's tcflush() and tcdrain() functions, where tcflush discards
> input and/or output data.

(For *nix, implementations of that are in unit termio)

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

Re: (Unix) serial port handling

Henry Vermaak
In reply to this post by Mark Morgan Lloyd-5
On 09/03/11 11:30, Mark Morgan Lloyd wrote:

> Henry Vermaak wrote:
>> On 08/03/11 10:30, Mark Morgan Lloyd wrote:
>>> Can anybody say whether there is a good reason that serial.pp lacks a
>>> function to read the CD signal?
>>>
>>> Is SerFlush, which calls fpfsync, intended to discard input data, output
>>> data or both?
>>
>> fsync just makes sure all the in-kernel caches are written to the
>> device. Flushing input data is just a matter of reading it.
>
> Thanks for that Henry. Obviously there's scope for confusion here with
> the kernel's tcflush() and tcdrain() functions, where tcflush discards
> input and/or output data.

You're right.  Thinking about it, I don't know what the use of an fsync
is in SerFlush, since you still don't know if it's been transmitted.
I'd consider this a bug, SerFlush should use tcdrain.

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

Re: (Unix) serial port handling

Mark Morgan Lloyd-5
Henry Vermaak wrote:

> On 09/03/11 11:30, Mark Morgan Lloyd wrote:
>> Henry Vermaak wrote:
>>> On 08/03/11 10:30, Mark Morgan Lloyd wrote:
>>>> Can anybody say whether there is a good reason that serial.pp lacks a
>>>> function to read the CD signal?
>>>>
>>>> Is SerFlush, which calls fpfsync, intended to discard input data,
>>>> output
>>>> data or both?
>>>
>>> fsync just makes sure all the in-kernel caches are written to the
>>> device. Flushing input data is just a matter of reading it.
>>
>> Thanks for that Henry. Obviously there's scope for confusion here with
>> the kernel's tcflush() and tcdrain() functions, where tcflush discards
>> input and/or output data.
>
> You're right.  Thinking about it, I don't know what the use of an fsync
> is in SerFlush, since you still don't know if it's been transmitted. I'd
> consider this a bug, SerFlush should use tcdrain.

I was using this to communicate with an HP instrument a few weeks ago,
so have my own re-implementation of some of the stuff. I'll look at
doing a patch, preparatory to seeing if I can hack a complementary
Win-32 equivalent.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re: [fpc-pascal] (Unix) serial port handling

John Lee-2
On , Mark Morgan Lloyd <[hidden email]> wrote:

>
> I was using this to communicate with an HP instrument a few weeks ago, so have my own re-implementation of some of the stuff. I'll look at doing a patch, preparatory to seeing if I can hack a complementary Win-32 equivalent.
>

Mark, afaik there isn't a way of reading com ports for xp/w7 etc in the fpc win distro at the moment -hope you'll be able to hack it soon either as part of the distro or as a contrib!

Or did I miss something?

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

Re: Re: [fpc-pascal] (Unix) serial port handling

Henry Vermaak
On 9 March 2011 15:54,  <[hidden email]> wrote:

> On , Mark Morgan Lloyd <[hidden email]> wrote:
>
>>
>> I was using this to communicate with an HP instrument a few weeks ago, so
>> have my own re-implementation of some of the stuff. I'll look at doing a
>> patch, preparatory to seeing if I can hack a complementary Win-32
>> equivalent.
>>
>
> Mark, afaik there isn't a way of reading com ports for xp/w7 etc in the fpc
> win distro at the moment -hope you'll be able to hack it soon either as part
> of the distro or as a contrib!
>
> Or did I miss something?

In Windows you use CreateFile and (Read|Write)File.
(Set|Get)CommState, EscapeCommFunction, and friends do the serial port
specific stuff.

There is no nice cross platform pascal implementation included in
freepascal, though, to my knowledge.  They exist in other packages, as
you've probably seen on this list.

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

Re: (Unix) serial port handling

Mark Morgan Lloyd-5
Henry Vermaak wrote:

> On 9 March 2011 15:54,  <[hidden email]> wrote:
>> On , Mark Morgan Lloyd <[hidden email]> wrote:
>>
>>> I was using this to communicate with an HP instrument a few weeks ago, so
>>> have my own re-implementation of some of the stuff. I'll look at doing a
>>> patch, preparatory to seeing if I can hack a complementary Win-32
>>> equivalent.
>>>
>> Mark, afaik there isn't a way of reading com ports for xp/w7 etc in the fpc
>> win distro at the moment -hope you'll be able to hack it soon either as part
>> of the distro or as a contrib!
>>
>> Or did I miss something?
>
> In Windows you use CreateFile and (Read|Write)File.
> (Set|Get)CommState, EscapeCommFunction, and friends do the serial port
> specific stuff.
>
> There is no nice cross platform pascal implementation included in
> freepascal, though, to my knowledge.  They exist in other packages, as
> you've probably seen on this list.

[Nod] There's obviously Synaser, but there's also the freeware TComPort
by Dejan Crnila which is well-regarded by Delphi hackers with unusual
requirements.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: (Unix) serial port handling

Mark Morgan Lloyd-5
In reply to this post by Henry Vermaak
Henry Vermaak wrote:

> On 09/03/11 11:30, Mark Morgan Lloyd wrote:
>> Henry Vermaak wrote:
>>> On 08/03/11 10:30, Mark Morgan Lloyd wrote:
>>>> Can anybody say whether there is a good reason that serial.pp lacks a
>>>> function to read the CD signal?
>>>>
>>>> Is SerFlush, which calls fpfsync, intended to discard input data,
>>>> output
>>>> data or both?
>>>
>>> fsync just makes sure all the in-kernel caches are written to the
>>> device. Flushing input data is just a matter of reading it.
>>
>> Thanks for that Henry. Obviously there's scope for confusion here with
>> the kernel's tcflush() and tcdrain() functions, where tcflush discards
>> input and/or output data.
>
> You're right.  Thinking about it, I don't know what the use of an fsync
> is in SerFlush, since you still don't know if it's been transmitted. I'd
> consider this a bug, SerFlush should use tcdrain.

It occurs to me that an fsync could possibly have a useful effect if a
badly-written driver (or suspect hardware) occasionally lost Tx interrupts.

I've submitted a patch as 0018946. I don't know whether anybody else is
using this unit but I'm trying not to break anything: I've marked
SerFlush as deprecated and added SerSync and SerDrain which are
non-destructive, and SerFlushInput and SerFlushOutput which are
destructive. This brings naming into line with the termio API, and
hopefully means that anybody working at this level doesn't have to
import termio explicitly.

Next job is writing Win-32 equivalents.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal