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

[Bo Berglund]

On Fri, 08 Oct 2010 07:29:47 +0000, Mark Morgan Lloyd
<markMLl.lazarus at telemetry.co.uk> wrote:

>Bo Berglund wrote:
>
>> A question concerning gtkterm:
>> I cannot find any command to open/close the port. How is that done?
>> Do I have to shut down the program to release the port?
>
>[Checks] You don't, the designated port is open as long as the program 
>is running. However you need to distinguish between "open", "in use" and 
>"locked": there is a convention that when a program wants to claim usage 
>of a port it writes a file containing its PID:
>
># ls -l /var/lock
>total 12
>-rw-r--r--    1 root     root           11 Aug 16 17:02 LCK..ttyS11
>-rw-r--r--    1 root     root           11 Oct  2 14:38 LCK..ttyS6
>drwxr-xr-x    2 root     root         4096 Mar 16  2010 subsys
>
>There are times when having multiple programs looking at a port can be 
>extremely useful, for example gettys tend to work like that. However 
>managing these PID files reliably can be a lot of effort.
>
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....

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?

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

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


Bo Berglund