Error on using hardware Raspberry Pi Inno-Maker RS485&CAN Module with TLAZserial

[ThomasK]

Hi,

I use TLAZSerial with an isolated RS485 HAT connected to the Pi's native serial I/O and an USB to RS485 isolated device to communicate with several power meters using ModBus protocoll. That works fine.

I also want to use CAN so I bought the above mentioned HAT.
With the driver installed, I can see the 2 new serial ports:

pi@raspberrypi:~ $ ls -l /dev/ttyS*
crw-rw---- 1 root dialout   4, 64 Mär 14 13:10 /dev/ttyS0
crw-rw---- 1 root dialout 235,  0 Mär 14 13:10 /dev/ttySC0
crw-rw---- 1 root dialout 235,  1 Mär 14 13:10 /dev/ttySC1
pi@raspberrypi:~ $

When I use the Demo GPS Simulator application, I can select both /dev/ttySC0 & /dev/ttySC1 devices.
But when I try to open the port, I get the following error message:

"Could not open device /dev/ttyS-2"

I tried it with GTKTerm, but here the two devices /dev/ttySC0 & /dev/ttySC1 do not show up in the selectable device list. Connecting USB adapter it works.

I already wrote to innomaker, but since GTKterm does not show the devices I have no clue where the problem lies. I searched the forum for the term "/dev/ttyS-2" without result.

Thanks and Best Regards.
 

[MarkMLl]

You get a bonus point for checking with gtkterm. Two possible things to try: (i) look at serial.pp which comes with FPC (i.e. not Lazarus), it doesn't try to check the validity of the name parameter. (ii) step into the LazSerial code that opens the port, and see if it's trying to parse the name e.g. as part of an attempt to list valid serial ports.

I must admit that I've never seen the ttySC* form, and I've spent a fair amount of time with kernel documentation etc. working out valid names. What type of device actually implements it, and does it really use the serial API?

MarkMLl

[winni]

Hi

Since Linux kernel 2.4 (~ 2000) /dev/ttyS2 is not a legal device name anymore.

It was renamed to   /dev/tts/2

Winni

[MarkMLl]

Rubbish.


$ ls -lt /dev/ttyS*
crw-rw---- 1 root dialout 4, 65 Feb 26 09:00 /dev/ttyS1
crw-rw---- 1 root dialout 4, 66 Feb 26 09:00 /dev/ttyS2
crw-rw---- 1 root dialout 4, 67 Feb 26 09:00 /dev/ttyS3
crw-rw---- 1 root dialout 4, 64 Feb 26 09:00 /dev/ttyS0


...and before anybody calls me out for being undiplomatic, I suggest referring to

https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/devices.txt

specifically char device major 4.

MarkMLl

[winni]

No Mister Rubbish

You are not undiplomatic .


You just have no knowledge about Linux history.

If you had then you should have said:

"devfs is not up-to-date"

Have a nice rubbish time

Winni

[MarkMLl]

@winni, the link I cited is Torvalds's own documentation. /dev/ttyS* is still the name for PC-style UARTS... if you believe otherwise then produce an authoritive reference and if you can't then stop muddying the water.

MarkMLl

[winni]

@winni, the link I cited is Torvalds's own documentation. /dev/ttyS* is still the name for PC-style UARTS... if you believe otherwise then produce an authoritive reference and if you can't then stop muddying the water.

MarkMLl

Read the kernel specification about 2.4 and the devfs.
And the come back.

The fact the the 2 CV is an oldtimer does not mean that there was never one.
Gosh

[trev]

Starting with kernel 2.4, a new system of device naming was created. It makes it easy to deal with a huge number of devices. But there's an option to continue using the old names. However, a new device may not have an old-style name so then one must use the new devfs. For a detailed description of it see: https://web.archive.org/web/20090504075850/http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html. Also see the kernel documentation tree: filesystems/devfs.

[Jurassic Pork]

hello,

devfsd is a device manager for the Linux kernel. Primarily, it creates device nodes in the /dev directory when kernel drivers make the underlying hardware accessible.[1] The nodes exist in a virtual device file system named devfs. In systems that support many different types of hardware, each of which has its own device nodes, this is more convenient than creating all possible device nodes beforehand and in a real filesystem.

While devfs was a step forward, it had several disadvantages of its own.[2] Since version 2.5 of the Linux kernel, devfs has been succeeded by udev and devtmpfs.[3]

Friendly, J.P

[MarkMLl]

While devfs was a step forward, it had several disadvantages of its own.[2] Since version 2.5 of the Linux kernel, devfs has been succeeded by udev and devtmpfs.[3]

In practical terms I think it's fair to say that the /dev/ttyS* devices are a special case since apart from anything else there appears to be a general convention that four device nodes always exist irrespective of whether there are corresponding physical devices. I think this comes from the kernel because of long-term problems enumerating legacy devices, but it's a long time since I've had to poke around that particular area.

It used to be that /dev/ttyS* was also used for "dumb" multiport PCI etc. cards which could be enumerated, but it's a long time since I've seen one. I'd be open to the suggestion that the /dev/tts* series was being used in this case, but am just a bit sceptical since they don't appear in Torvalds's https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/devices.txt which is a definitive kernel document and is being maintained.

I'm obviously familiar with the other series of names: /dev/ttyUSB*, /dev/ttyACM*, /dev/ttyAM* and the rest, as well as older names for things like ISDN ports which still were broadly handled by the serial API.

I'm slightly concerned by OP's /dev/ttySC* names but I presume they correspond to


       205 = /dev/ttySC0      SC26xx serial port 0
       206 = /dev/ttySC1      SC26xx serial port 1
       207 = /dev/ttySC2      SC26xx serial port 2
       208 = /dev/ttySC3      SC26xx serial port 3


where the SC26xx are apparently NXP devices. https://linux-kernel.vger.kernel.narkive.com/MR53ugNh/serial-sc26xx-device-name might be relevant, but at this point I think we really do need to know what kernel module OP sees being loaded (dmesg output) and I think we also need him to step through the device open sequence in case the name is getting mnagled... only he can do that since I don't think that anybody else here has that hardware.

@JurassicPork: had an interesting one yesterday. I added a SIGUSR1 handler to a program to extract timing info while it was running, and found it broke timeout code in serial.pp. I need to revisit that at some point but aren't looking forward to it since I'll need to recreate a SunOS/Solaris system for testing since there are differences in the way fpSelect() works.

MarkMLl

      

[ThomasK]

Hi,

I found /tty/SC0 twice in the mentioned text document.
I am not a specialist in controlling devices, but I think, that the lazsynafpc.pas does not take care of the variant /tty/SCx devices.

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

1. procedure TBlockSerial.GetComNr(Value: string);
2. begin
3.   FComNr := PortIsClosed;
4.   if pos('COM', uppercase(Value)) = 1 then
5.     FComNr := StrToIntdef(copy(Value, 4, Length(Value) - 3), PortIsClosed + 1) - 1;
6.   if pos('/DEV/TTYS', uppercase(Value)) = 1 then
7.     FComNr := StrToIntdef(copy(Value, 10, Length(Value) - 9), PortIsClosed - 1);
8. end;

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

1.   if FComNr <> PortIsClosed then
2.     FDevice := '/dev/ttyS' + IntToStr(FComNr);
3.   // Comport already owned by another process?          {HGJ}
4.  
5.     ScanForPorts( '/dev/rfcomm*',true);
6.  //   ScanForPorts( '/dev/pts/*');
7.     ScanForPorts( '/dev/ttyUSB*',true);
8.     ScanForPorts( '/dev/ttyS*',false);
9.     ScanForPorts( '/dev/ttyAM*',true); // for ARM board
10.  

the scan for ports will find /dev/ttySn and /dev/ttySCn but will rest of the unit treats the equal.

my four cents.

[MarkMLl]

I am not a specialist in controlling devices, but I think, that the lazsynafpc.pas does not take care of the variant /tty/SCx devices.

I think the code you posted shows at least part of the problem, but is that used when opening the port or just when an attempt is being made to enumerate available devices?

What happens when you use serial.pp? I did the last maintenance on that and it's a very thin wrapper around the OS calls, so isn't going to reject a name in a form it doesn't recognise.

MarkMLl

[sstvmaster]

Same problem: https://www.raspberrypi.org/forums/viewtopic.php?t=297282

[MarkMLl]

Same problem: https://www.raspberrypi.org/forums/viewtopic.php?t=297282

Something that stands out in that is that he was using


dmesg | grep tty


etc. rather than


dmesg | tail -25


My suspicion is that the stuff logged in dmesg depends entirely on messages being generated by kernel modules, and if for some reason those messages don't include what's being grepped for then he'll be missing important stuff.

In this sort of situation the most useful commands are


$ ls -lt /dev | head -25
$ dmesg -e | tail -25


both of which will have useful human-readable timestamps. Following on from that, if the OS has recognised the device then there will be something in the /sys/class tree... it's unlikely that the demo programs are bit-banging a memory-mapped device if they are actually identifying it as /dev/ttySC*.

MarkMLl

[ThomasK]

Hi,

using serial.pp opens and closes both devices (/dev/ttySC0 & /dev/ttySC1) and returns a handle.