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?

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

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.

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

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.

In our previous episode, Mark Morgan Lloyd said:

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

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

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 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'ta 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

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

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

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.