Virtual serial ports created with socat not compatible with Xojo

Using a command like socat -d -d pty,raw,echo=0 pty,raw,echo=0 creates a pair of virtual, linked, serial ports. However, these ports don’t seem to be compatible with Xojo’s Serial API. SerialDevice.Count doesn’t include the virtual ports in the number it returns. And trying to access these ports using SerialDevice.WithName returns an ‘Error 25’, which translates to 'Inappropriate ioctl for device’.
Using screen from the command line connects to these ports just fine.

Does anyone know why that is. Is it a shortcoming in Xojo?

Deleted previous reply since I initially didn’t see you were on MacOS.

For what it’s worth, it looks like Necat (man nc) is installed with base MacOS install.

If it’s got the features you need, it might behave better/have fewer issues than with socat?

I didn’t think netcat can create virtual serial ports, can it? Do you know of an example you can point me towards? My search came up empty.

Roger - Did you find any solution? I’m in the same boat trying with virtual serial ports but SerialDevice only seems to show the /dev/cu.* devices and the ones I create with socat are obviously ttyS…
Thanks

No, I haven’t found a solution yet, unfortunately.

Here is another reason why it is critical that virtual serial ports are supported by Xojo. Traditional bluetooth modules with a serial port profile, which many people have been using to communicate with hardware wirelessly using serial terminals like CoolTerm, are being phased out in favor of Bluetooth LE hardware. BLE no longer supports serial profiles, so BLE-Serial bridges (such as ble-serial) are necessary to allow access of BLE hardware via virtual serial ports. However, just like serial ports created by socat, these virtual serial ports are not enumerated by SerialDevice and when connecting to these ports using the port name, an error 25 is thrown.

1 Like

I have found the exact call that causes the error. To activate any port settings, the ‘Reset’ method of the SerialConnection control needs to be called. That’s when the error is raise. Unfortunately, I have no idea what happens exactly under the hood when “Reset” is called, but it is when things like baudrate, databits, stop bits, flowcontrol, etc is applied. I have no way of telling which setting is the offending one since I have to assume they are all set during a call to “Reset”. This means there is no way to know what the actual port settings are.

Have you tried SerialPortMBS class?

I haven’t. Aside from this particular issue “MARK” and “SPACE” parities not working on anything other than Windows platforms, the SerialConnection control in Xojo has actually worked very well for me.

The workaround for the issue with virtual ports is to simply ignore error 25 and connect to the port regardless. The connection DOES work, and hardware settings such a baudrate, etc, don’t seem to matter for such ports anyways.