Hi,

If somebody with more experience (than me) with the Synaser and FPC serial.pp units could comment, that would be much appreciated.

For a new cross-platform project where I need to talk to a device hooked up to a serial port, which unit would be the best to use? Normally I would go with units included with FPC simply because I know they are strict about keeping everything maintained.

When I say cross-platform, I'm currently talking about Windows and Linux, and possibly FreeBSD and Mac too.

Now for the Synaser unit - the one I have is from 2013, and I already noticed that there is no support for FreeBSD's /dev/* names to access serial ports. Granted I added FreeBSD support to the GetSerialPortNames() function in 5 minutes, but this doesn't bode to well then for the Synaser unit - what else could be missing that I don't know of?

Regards,
Graeme

Dne 17.08.2017 v 15:45 Graeme Geldenhuys napsal(a):

For most actual Synaser version you must look at Synapse SVN server. ;-)

Synaser have class TBlockSerial. It can work with *any* device name. (It know to emulate Windows COMxx names on Linux too.)

GetSerialPortnames is just helper funcion, what is designed for windows only first. Some platforms are added later, but it cannot be fully multiplatform. However it is just helper for get list of existing serial ports. If you know serial device name, you not need it.

Lukas Gebauer

gebylist wrote

For most actual Synaser version you must look at Synapse SVN server.;-) Synaser have class TBlockSerial. It can work with*any* device name. (It know to emulate Windows COMxx names on Linux too.)

Thank you Lukas, I'll make sure to get the latest from SVN and go from there. I'll probably try both Serial.pp and Synaser just to make sure.

Regards,
Graeme

I see the common Linux port names got added to Synaser (trunk) but the BDS variants (https://sourceforge.net/p/synalist/bugs/21/) wasn't added.

I've also just noted a typing error in GetSerialPortNames: '/dev/ttyAM*' should rather be '/dev/ttyACM*''

On Thu, Aug 17, 2017 at 3:45 PM, Graeme Geldenhuys <

I did the last maintenance on the serial.pp unit. I was focussing on very low-level stuff, i.e. capture in threads with accurate timestamps being appended, and notwithstanding my experience in this area would suggest looking first at Synaser etc. which is far more likely to have e.g. compatible terminal emulation.

I did specifically test serial.pp with both Linux (various processors) and Solaris (SPARC) and to a lesser extent Windows (W2K, x86). There's a specific gotcha related to differences in the way Linux and Solaris handle select(), and since AIUI Solaris and the Berkeley OSes are related this might turn out to be more of an issue that things like naming conventions.

I'm not aware of a reliable, cross-platform way of getting a complete list of all serial-like devices. I suppose that in principle it would be possible to try out the appropriate ioctls on all character devices, but things might break.

Mark Morgan Lloyd wrote

There's a specific gotcha related to differences in the way Linux and Solaris handle select(),

I saw some of those in th serial.pp in FPC trunk. Thanks for the information.

I'm not aware of a reliable, cross-platform way of getting a complete list of all serial-like devices.

To be honest, this is not much of an issue - more of a nice-to-have. It will only need to be set up once for the application anyway.

Regards,
Graeme

Christo Crause wrote

I've also just noted a typing error in GetSerialPortNames: '/dev/ttyAM*' should rather be '/dev/ttyACM*''

My version also has the first instance (ttyAM*) with a comment "ARM boards". Your implementation in the bug report looks a lot better than what I have in my synaser copy - cleaner code with less code duplication. Thanks for the reply.

Regards,
Graeme

I've got this terrible habit of inserting comments... :-)

> I'm not aware of a reliable, cross-platform way of getting a complete> > list of all serial-like devices. To be honest, this is not much of an issue - more of a nice-to-have. It will only need to be set up once for the application anyway.

This is more of an issue than it used to be since, as a particular example, if something like an Arduino resets itself the kernel is likely to assign this a new named device. Having to restart an app to track this is irritating, but tracking udev (or whatever) events is probably overkill.

I'd suggest that a good policy would be to recognise various patterns at startup (/dev/ttyS*, /dev/ttyUSB* and so on) and to be prepared to accept incrementing numeric suffixes as they appear.

Mark Morgan Lloyd wrote

> I saw some of those in th serial.pp in FPC trunk. Thanks for the > information. I've got this terrible habit of inserting comments...:-)

You and I must be a rare breed of programmer then. :-)

Regards,
Graeme

On Fri, Aug 18, 2017 at 9:39 AM, Graeme Geldenhuys <

Right, not a typo then. Good to learn something new - apparently ttyAMA* is the device name specified by the ARM AMBA style serial ports driver for Linux: (
https://code.woboq.org/linux/linux/drivers/tty/serial/amba-pl011.c.html#2514 )

So I looked for a systematic naming convention, but according to the Linux allocated devices list (
https://static.lwn.net/kerneldoc/admin-guide/devices.html) there is a large number of tty* names in use for different serial drivers. Perhaps a different approach (https://stackoverflow.com/a/9914339) is called for...

So I looked for a systematic naming convention, but according to the Linux allocated devices list (https://static.lwn.net/kernel doc/admin-guide/devices.html) there is a large number of tty* names in use for different serial drivers. Perhaps a different approach ( https://stackoverflow.com/a/9914339) is called for...

When I implemented the pascalscada serial port component, I decided to use serial.pp to avoid one more package dependency and missing features in synaser at the moment that I started the Implementation (2010/2011). So I implemented the missing features directly on pascalSCADA serial port.

To enumerate serial ports on Linux, the stackoverflow link of the last message is the best approach that I tested, but works only on Linux. For BSDs, MacOS and Solaris, I still using the approach of name pattern with numbered suffixes. On Windows BuildCommBCD Windows API function can be used, similar to the approach used FreeBSD, Mac e Solaris...