TLazSerial : serial port component for Lazarus (windows and linux).

[Jurassic Pork]

Hello,

I'm doing this on Lazarus 2.2.0 on macOS Catalina - as I noticed that, as of version 0.6, TLazSerial supports macOS. I've opened the package file, then clicked on Use -> Install. I get prompted to re-compile Lazarus, which I do, and it stops with the error

Code: Pascal  [Select][+][-]

1. idewindowintf.pas(26,3) Fatal: Cannot find IDEOptionsIntf used by IDEWindowIntf, incompatible ppu=/Applications/Lazarus/components/buildintf/units/x86_64-darwin/ideoptionsintf.ppu, multiple packages: BuildIntf, IDEIntf

Have a look     here :   Compiling aborts with error message "Cannot find IDEOptionsIntf used by IDEWindowIntf

Friendly, J.P   

[geraldholdsworth]

Thank you J.P.

That did the trick. However, it then stopped at another file, then another, and so on. It's currently looking for a macrointf.pas file. I'll attack it again later on, when I have more time and patience.

[geraldholdsworth]

Finally got it installed OK. It keep aborting while looking for that macrofint.pas file - I just found an option, on the package dialogue box thingy, to recompile everything. This fixed the issue.

Now to try and use it - already found out how to get a list of available ports, now just need to work out how to send something. Oh, and it works fine on my Mac (at least, it tells me what ports are available) - although I'm not sure it'll work on your Zeddie, J.P.

[geraldholdsworth]

I actually found I could use the LazSynaSer unit directly. However, this has a major bug in it which causes the application to hang in macOS. It also does it if you use TLazSerial (as this is just a wrapper). It is caused by the creation of the lock file. It is hard coded to create a directory, then files in that directory, in '/var/lock' but the system disallows the creation of anything in the '/var' directory without admin password. So, in LazSynaSer (the one in the TLazSerial download), I have made the following edits:
Line 128:

Code: Pascal  [Select][+][-]

1. //LockfileDirectory = '/var/lock'; {HGJ}

(i.e., just comment out the line)
Add at the bottom of that const block (line 172):

Code: Pascal  [Select][+][-]

1. var LockfileDirectory:String;

Then, what is now line 2224, remove the extra backslash:

Code: Pascal  [Select][+][-]

1. result := LockfileDirectory + 'LCK..' + s;

and in the cpomComportAccessible function, add after the 'begin':

Code: Pascal  [Select][+][-]

1. LockfileDirectory:=GetTempDir;

This then ensures that the lock file is created in the temporary files location which doesn't need admin permission to access. I believe that this only affects Linux and macOS.

I haven't used it in anger yet, so it sends data but nothing comes back (as nothing is currently connected). That might happen tomorrow.

Can anyone else confirm that they experience the same issue with macOS?

[tetrastes]

I don't know about macOS, but at Linux there is no much sense to place lock file in directory where system doesn't look for lock files, except if only your program accesses this port. It is simpler to set TBlockSerial.LinuxLock property to false, though at Linux usually there is no problem with /var/lock.

By the way, there is ancient code in function TBlockSerial.cpomComportAccessible, which is still not corrected (from synaser.pas in the last trunk of Synapse):

Code: Pascal  [Select][+][-]

1.   // Is port owned by orphan? Then it's time for error recovery.
2.   //FPC forgot to add getsid.. :-(
3.   {$IFNDEF FPC}
4.   if {$IFNDEF POSIX}Libc.{$ENDIF}getsid(ReadLockfile) = -1 then
5.   begin //  Lockfile was left from former desaster
6.     DeleteFile(Filename); // error recovery
7.     CreateLockfile(MyPid);
8.     result := FileExists(Filename);
9.     exit;
10.   end;
11.   {$ENDIF}

FPC has fpGetsid for many years...

[Jurassic Pork]

Hello,

I don't know about macOS, but at Linux there is no much sense to place lock file in directory where system doesn't look for lock files, except if only your program accesses this port. It is simpler to set TBlockSerial.LinuxLock property to false, though at Linux usually there is no problem with /var/lock.

in the constructor of TLazserial the LinuxLock property is set to false :

Code: Pascal  [Select][+][-]

1. constructor TLazSerial.Create(AOwner: TComponent);
2. begin
3.   inherited;
4.   //FHandle:=-1;
5.   ReadThread:=nil;
6.   FSynSer:=TBlockSerial.Create;
7.   FSynSer.LinuxLock:=false;
8.   FHardflow:=false;
9.   FSoftflow:=false;
10.   FFlowControl:=fcNone;
11.   {$IFDEF LINUX}
12.   FDevice:='/dev/ttyS0';
13.   {$ELSE}
14.   FDevice:='COM1';
15.   {$ENDIF}
16.   FRcvLineCRLF := False;;
17. //  FBaudRate:=br115200;
18. end;  

     

Friendly, J.P             

[geraldholdsworth]

Maybe a better idea is to ditch the lockfile idea for macOS, but put it back for Linux. The latest I've found (from earlier this year) has a fix for Android which does exactly that, so I'll go through and affect a similar fix to this file, but for macOS.

[tetrastes]

in the constructor of TLazserial the LinuxLock property is set to false :

Yes, but

I actually found I could use the LazSynaSer unit directly. However, this has a major bug in it which causes the application to hang in macOS.

In lazsynaser LinuxLock is set to true, as in original synaser.

And then I don't understand this

It also does it if you use TLazSerial (as this is just a wrapper). It is caused by the creation of the lock file.

[geraldholdsworth]

And then I don't understand this

It also does it if you use TLazSerial (as this is just a wrapper). It is caused by the creation of the lock file.

OK, confused myself now - now not sure why the test program for TLazSerial hangs my machine. By setting the LinuxLock to false, it shouldn't try to create a lockfile, under any OS. I need to play some more.

[geraldholdsworth]

OK, got it. It appears that the lockfile wasn't causing a hang, but this line (in Connect function):

Code: Pascal  [Select][+][-]

1. FHandle := THandle(fpOpen(FDevice, SerialFlags));

The red herring here was that the lockfile, likely, got created (certainly did in the temporary location) but was never deleted. Upon the second time of trying to connect, this file already exists so the function exits. It is supposed to raise an error in this case, but this doesn't happen. As I had nothing on my RS232 ports, nothing was found - I'm sure once I connected what I'm intending to control and it didn't work, this might have then clicked.

[Jurassic Pork]

hello,
what is the problem ?
I have no problem to use Tlazserial on Mac OS 10.15 Catalina.
In attachment capture of lazserial test application in Action . Two USB serial ports sending to each other GPS frames (crossed cable)
And lazsynaser is only for TLazserial.
Friendly, J.P

[geraldholdsworth]

Just tried the test application again. Configured to use my USB-Serial adapter (but nothing on the other end), then clicked on Open and....it hangs. Same line in lazsynaser.

My adapter identifies itself as '/dev/tty.usbserial-1410', but I can't see that making a difference.

CoolTerm can connect to this same adapter without issue, so it can't be a permission thing in macOS.

[Jurassic Pork]

Are you using the 0.6 version of TLazserial (only available on my repository) ?

new in v0.6 version (03/2022)
 Fixes for OS-X (thanks to rphoover), SynSer(synaser) properties now persistent, v0.3 of GPS simulator
 On OS-X you must set the property  SynSer/NonBlock to True  in the properties of TLazserial component.

set the NonBlock property to true in the SynSer part of TLazserial component (see attachment)

[geraldholdsworth]

Ah...that did it. Thank you.

[Noobie]

I'm trying to read data from serial port. In every package has '#' as a first mark and '&' as an end mark but after the end mark there is also 16-bit CRC. With Lazserial it is easy to use "RecvTerminated" but how to get CRC in same package?