[Lazarus] Using 5dpo for serial comm...

[Mark Morgan Lloyd]

Bo Berglund wrote:

> I am used to the Windows world where you can manage the com port data
> prior to actually opening it. Then you use it for a while, close it
> and continu other stuff. Later again you can open and use the port.
> If one tries to open a port that is either non-existing or already in
> use by another program, then there will be an exception.
> But in my Linux case where I only have a single com port there was
> nothing warning me that the port I opened was not really there...
> Hence my problems, I believed that the port was ttyS0 and not
> receiving an exception on open enhanced this belief. But in actual
> fact only ttyS1 is backed by real hardware, the others are just plain
> files by the looks of it. Strange....

No, they're not files.

> In the case of gtkterm, does it actually open and use the com port as
> soon as it starts? How can it know in advance *which* port the user
> wants it to use?

Configuration file.

> It makes more sense to me to first specify port number, data speeds
> and such and only then open the port, send the data or whatever, and
> finally close the port. Then maybe go to another port and repeat the
> above...

There's two ways to look at that:

i)   Unix doesn't work like that. You need to get a handle for the 
device before you can set the Baud rate etc.

ii)  Windows doesn't work like that either :-)

Put another way, what you're saying is that you're used to setting up an 
object (term used loosely) representing a port before actually doing 
something with the port. That's not an OS issue, it's down to the class 
library etc.

> If hardware access is managed by "lock" files in /var/lock, then what
> will happen if the application fails to remove the lock file
> afterwards? Do we get a forever unaccessible com port???

I said it was hard work to get right, didn't I?

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

[Opinions above are the author's, not those of his employers or colleagues]