@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
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]
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]
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.
Same problem: https://www.raspberrypi.org/forums/viewtopic.php?t=297282
using serial.pp opens and closes both devices (/dev/ttySC0 & /dev/ttySC1) and returns a handle.
So wie ich es verstanden habe sind die Seriellen Ports vorhanden, nur kann LazSerial nicht damit umgehen.
Mit der serial.pp und "/dev/ttySC*" funktioniert es ja.
Vielleicht kann Jurassic Pork LazSerial dahin gehend erweitern. Eventuell kann er auch deinen Regex nutzen.
When I use the Demo GPS Simulator application, I can select both /dev/ttySC0 & /dev/ttySC1 devices.i have found where there is a problem to use a port like /dev/ttySC0
But when I try to open the port, I get the following error message:
"Could not open device /dev/ttyS-2"
"Could not open device /dev/ttyS-2"
I try to modify both procedures to differentiate between different length of device basic names:
I found quite a large variety in the mentioned device list:
/dev/ttySnnn UART serial port device
/dev/ttySAn Strong ARM builtin serial port
/dev/ttySCn SC26xx serial port
/dev/ttySCn SCI serial port
/dev/ttySGn SGI Altix console port
/dev/ttySIn SmartIO Port
/dev/ttySRnnn RIO port
/dev/ttySMXn Motorola i.MX - port
/dev/ttySIOCnn Altix ioC3 serial card
/dev/ttySAn Strong ARM builtin serial portFcomNr value is -2 and you doesn't alter the device name
/dev/ttySCn SC26xx serial port
/dev/ttySCn SCI serial port
/dev/ttySGn SGI Altix console port
/dev/ttySIn SmartIO Port
/dev/ttySRnnn RIO port
/dev/ttySMXn Motorola i.MX - port
/dev/ttySIOCnn Altix ioC3 serial card
I try to modify both procedures to differentiate between different length of device basic names:
I found quite a large variety in the mentioned device list:
/dev/ttySnnn UART serial port device
/dev/ttySAn Strong ARM builtin serial port
/dev/ttySCn SC26xx serial port
/dev/ttySCn SCI serial port
/dev/ttySGn SGI Altix console port
/dev/ttySIn SmartIO Port
/dev/ttySRnnn RIO port
/dev/ttySMXn Motorola i.MX - port
/dev/ttySIOCnn Altix ioC3 serial card
have you try only my change :
if FComNr > PortIsClosed then
Friendly, J.P
Plus /dev/rfcomm*, plus /dev/AMA0 for an RPi. See message #17, the only reliable way of doing this is to match /dev/tty, then process the letters and digits that follow separately.
MarkMLl
With the procedure GetComNr :
procedure TBlockSerial.GetComNr(Value: string); begin FComNr := PortIsClosed; if pos('COM', uppercase(Value)) = 1 then FComNr := StrToIntdef(copy(Value, 4, Length(Value) - 3), PortIsClosed + 1) - 1; if pos('/DEV/TTYS', uppercase(Value)) = 1 then FComNr := StrToIntdef(copy(Value, 10, Length(Value) - 9), PortIsClosed - 1); end;
when the device is /dev/ttySC0 or /dev/ttySC1 or /dev/ttySD0 for example we have -2 in the FComNr variable, it is why you have :Quote"Could not open device /dev/ttyS-2"
what you can try, it is to replace this line in lazsynaser.pas :with this one :
if FComNr <> PortIsClosed then Not sure that it is the better solution but for /dev/ttySCx it doen't change the name of the device.
if FComNr > PortIsClosed then
recompile the package Lazserial after the change.
Don't forget that lazsynaser.pas come from synaser.pas then there is the same problem in synaser.
Friendly, J.P
In the meantime I checked the Python samples and found that they are using:Unfortunately TIOCGRS485 = 0x542E ff. definitions are not included in the termios.inc in the section ARM CPU. So I will continue Jugend forscht.
TIOCGRS485 = 0x542E TIOCSRS485 = 0x542F SER_RS485_ENABLED = 0b00000001 SER_RS485_RTS_ON_SEND = 0b00000010 SER_RS485_RTS_AFTER_SEND = 0b00000100 SER_RS485_RX_DURING_TX = 0b00010000
...
the general form is '\\.\COMxx' and the above code will have troubles with that.
...
After searching for the string "TIOCGRS485" I found that this missing in the TERMIOS definitions for ARM.
Okay, let's go through ...
lazsynaser.pas:929
procedure TBlockSerial.Connect(comport: string); // comport:='\\.\COM12' ... FBuffer := ''; FDevice := comport; // FDevice:='\\.\COM12' GetComNr(comport); // FComNr:=PortIsClosed (because both pos('COM', uppercase(Value)) <> 1 and pos('/DEV/TTYS', uppercase(Value)) <> 1 ... if FComNr <> PortIsClosed then // False! FDevice := '\\.\COM' + IntToStr(FComNr + 1); // Skipped FHandle := THandle(CreateFile(PChar(FDevice), GENERIC_READ or GENERIC_WRITE, 0, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL or FILE_FLAG_OVERLAPPED, 0)); // CreateFile() uses the same string as given in comport argument ...
My question is: What is the purpose of FComNr variable and GetComNr() method? (At least in Windows)
A little bit of clarification - my previous remark was based purely on the code snippet I saw in the discussion. I do not use the LazSerial component and I am not familiar with it.
Regards,
x may be any.
After searching for the string "TIOCGRS485" I found that this missing in the TERMIOS definitions for ARM.
Specifically, it's in aarch64 but not in the 32-bit section. If it works, report the omission as a bug on Mantis.
MarkMLl
I got it to work. I will post later the code snippets. How can I report this as a bug? Do you have a link?
@ThomasK If they don't go into the bugtracking system they will get lost. It's your responsibility to do that.
MarkMLl
Just done 0038763, I had to register first - now I go walk the dog.