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

[tetrastes]

Do you want to apply the changes in the latest .7z and upload a new one?
Or I can do it, but the chance of making an error increases.

Of course you can. Just in case, I attach lazsynaser-new.pas also.

There are also some pull requests, I wonder if I shall apply them:
https://github.com/JurassicPork/TLazSerial/pulls

It's up to you to decide.

If I remeber (some of) these from lazsynaser.pas also have different names:

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

1.   dcb_Binary = $00000001;
2.   dcb_ParityCheck = $00000002;
3.   dcb_OutxCtsFlow = $00000004;
4.   dcb_OutxDsrFlow = $00000008;
5.   dcb_DtrControlMask = $00000030;
6.   dcb_DtrControlDisable = $00000000;
7.   dcb_DtrControlEnable = $00000010;
8.   dcb_DtrControlHandshake = $00000020;
9.   dcb_DsrSensivity = $00000040;
10.   dcb_TXContinueOnXoff = $00000080;
11.   dcb_OutX = $00000100;
12.   dcb_InX = $00000200;
13.   dcb_ErrorChar = $00000400;
14.   dcb_NullStrip = $00000800;
15.   dcb_RtsControlMask = $00003000;
16.   dcb_RtsControlDisable = $00000000;
17.   dcb_RtsControlEnable = $00001000;
18.   dcb_RtsControlHandshake = $00002000;
19.   dcb_RtsControlToggle = $00003000;
20.   dcb_AbortOnError = $00004000;
21.   dcb_Reserveds = $FFFF8000;    

These are from Win32 API https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-dcb.

Maybe some of these:
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddser/ns-ntddser-_serial_handflow

I don't think there is any need in Windows Drivers API, but again, it's up to you to decide. This is your fork of LazSerial now. 
 

[CM630]

Of course you can. Just in case, I attach lazsynaser-new.pas also.

Applied and attached.

I don't think there is any need in Windows Drivers API, but again, it's up to you to decide. This is your fork of LazSerial now. 

For people like me, which know nothing about serial communication, it is better to be able to get the connection properties from the sniffer and apply it.
I understand nothing about DTR, RTS, parity, etc. As long as I need to connect a device to the PC, I have to reproduce what it expects, the connection parameters are already selected by someone else.
 The changes I made in TLazSerial are related to port listing, the only exception is that I added selectable baudrate.

This is your fork of LazSerial now. 

I do hope that @JP is not gone forever.

EDIT: I added some info in the wiki: https://wiki.freepascal.org/Hardware_Access#TLazSerial
EDIT2: Uploaded a new version, .ShowSetupDialog was not working. Also added an Arduino sample for Test1.

[seppde]

@CM630 would you mind creating an actual fork with your Version 0.7 of TLazSerial on Github? Currently, the only source for this version are the attached zip files in your posts.

[CM630]

Here it is:
https://github.com/CM630/TLazSerial

I still hope it is temporary, until JP is back.

Edit: I will add this link in the wiki after EO Easter.
Edit 1: Info added to https://wiki.freepascal.org/Hardware_Access#TLazSerial_(LazSerialPort)

[CM630]

Added more flow control values.
Not uploaded to a repository yet.

[CM630]

Windows likes assigning the same name to multiple com ports (for example currently I have COM11 twice).
So I wonder how to list them in the serial selector:
1. List all instances with corresponding friendly names and serial numbers.
  Example:
  COM1 (Inbuilt serial port)
  COM5 (Virtual serial port)
  COM5 (USB STM 2424235432)
  COM12 (USB Serial CH431)

or

2. Duplicated ports listed once with a separator, for example “|”
  Example:
  COM1 (Inbuilt serial port)
  COM5 (Virtual serial port | USB STM 2424235432)
  COM12 (USB Serial CH431)

or

3. List the port once with info “Multiple instances”.
  Example:
  COM1 (Inbuilt serial port)
  COM5 (Multiple instances (something is wrong))
  COM12 (USB Serial CH431)

or

4. Make it optional


Method 1 will take most efforts, but it will look like in the Windows dev manager.
On the other hand, one (at least I) never knows what will happen when trying to connect to a duplicated port.
In some cases one of the ports is displayed as working while the other one with the same name is displayed with an error. It would be better if some error indication is displayed in the serial selector, too, I do not know if it is possible.


Maybe somebody else's opinion will be helpful.

[mas steindorff]

if me and windows 10, this is due to the port not being closed between USB cycle events. in this case, I do get a 1:1 after restarting the program and rescanning the ports. this is why closing the port correctly is important
How do you scan for Comm ports? I tend to use the registry
MAS

[Mike.Cornflake]

I'm a windows user, and I only ever see duplicate com ports when I'm first configuring hardware.  Either I've got driver issues or a pending reboot I should have done a while ago "but I'll just just do this one other thing first".

So for me, option 3 is the preferred.

[CM630]

There occur to be four major manufacturers of serial to USB chips + STM32, which embed the serial interface in the CPU. There are also clones/counterfites of these.

One of these manufacturers is Prolific, there are several issues with their drivers, one of which is that (sometimes) after a device is unplugged, it is not removed from the registry.
This is one of the reasons not to get the list of the devices from the registry, but from a windows service (Win32_PnPEntity). In TSerialSelector this is named WMI mode and is switchable from the properties.

Also, when multiple devices have been plugged and unplugged in the same PC, their data is not removed from the registry.  So there might be multiple data for one and the same COM and getting friendly names (and serial № if available) is not reliable. This issue does not exist with WMI mode.

About multiple COMs with the same name at the same time - I have seen it in the following ocasions:
1. Blue/black pill with USB set to keyboard/ mouse, but for some reason recognised by windows as a COM port. In this case there is an error shown in the device manager.
2. Virtual device of com0com.
3. Maybe (I am not sure that I remember properly, so I have some doubt) with some Prolific devices, usually this gets fixed when refreshing the device manager or rather reinstalling the driver.

[mas steindorff]

Bluetooth SPP devices also stay around forever in widows depending on the BT dongle you use. I have not seen them step on one another like you have with your list but we often screen OFS devices since I push some devices pass the standard baud rates. I have the issue that I end up with +100 devices and some software can only handle a 2 digit Comm port selection. Once a year I have to go and clean my registry.
I would vote for #3 as well.  The way I use the the port is to check the name for "USB" or a name that is programed into the device.

[CM630]

Bluetooth SPP devices also stay around forever in widows depending on the BT dongle you use. ...

It is quite different. They stay, or at least windows thinks they are there.
With Prolific (PL2303) the device is unplugged, it is not present in the device manager, Windows is fully aware it is not there, but still its entry is present in the registry.

...OFS devices...

Google did not tell me what these are.

since I push some devices pass the standard baud rates.

Support for non-standad baudrates is added in TLazSerial a couple of months ago, maybe you can try that and provide some feedback?

Once a year I have to go and clean my registry.

I am seeking a solution even for those, who do not 

...The way I use the the port is to check the name for "USB" or a name that is programed into the device....

If I get you right, this is what TSerialSelector shows: COMx + Friendly name + serial number (some devices support ser№). All settable in options.

[LeP]

About multiple COM ports with same "name" like example 3:
 COM5 (Multiple instances (something is wrong))

I use the same port name for different hardware, since may be used from available market.
If I don't find specific device I used another and I assign the same "name" so the software can use it without knowing nothing about the hardware.

I do this with all my PC (in Windows) by default, so COM4 for example is always assigned to almost 2 different hardware devices.

Take care that not all hardware do an enumeration of Serial Port, I mean that they don't respond to any know enumeration API (but they still be show the existence in Windows).

And some of them, like FTDI derived devices, have a VCOM sdk that can be used to work with device outside Windows API (I don't know about Linux or other SO).

Normally I used them in RS485 configuration with speed from 921Kbits to 4Mbits, I don't use LazSerial (I'm with Delphi) and use very old component from 30 years ago (last update 15 years ago and some years ago by me). It works like a charm.

A note: in industrial environment Prolific devices are not commonly used 'cause old drivers issues. FTDI derived hardware is what you'll commonly find. Of course, this is for what I know.

[mas steindorff]

.. OFS devices...

sorry, I meant OTS for Off The Shelf which I should have just written it out

baud rate: I may have misspoken when I said I used LazSerial for this, I can't find the test code I used to talk to a FTDI USB<=>bridge chip @ 3,000,000 (3Mbit).  Maybe it failed and I then just went to something else (on the same PC) to continue the testing. if this was the case then it's something we can look into for LazSerial update.  I'll look into this when I have the hardware setup again.

[rant on]
The parameters for the TBlockSerial.config(Baud, parity, stops, handshaking,_) are becoming optional. For USB devices, they are little more than a message to the external chip for it's external 2 to 6 pin configuration and IMHO have little impact on the PC side. In fact, when connected to a USB enabled STM32, the baud rate parameter was completely ignored.  As a test, I set some at rates that mathematically could not keep up with the data stream rate but it still did.
One of FTDI's USB<=>RS323 chip uses the RTS (aka the holdoff signal from the PC) for it's own "buffer full" threshold signal to the microprocessor. in other words it's uses can not be turned off  by the PC when baud rates or over 1 Mbps
[/rant off]
MAS

[CM630]

Alas, I cannot get duplicated devices anymore 

Anyway, some changes:
1. Windows: Added a ⚠ sign, followed by the error code in the info (optional). I have not observed errors on attached devices in Linux, so no support for that.

2. Windows: Some devices generate DBT_DEVNODES_CHANGED, but they never send DBT_DEVICEARRIVAL or DBT_DEVICEREMOVECOMPLETE, so events OnComConnected and OnComDisconnected were not triggered.
A routine is added in SerialWatcher to refresh the device list when DBT_DEVNODES_CHANGED is sent alone.
I am still wondering if this is a good idea, since it causes some lag in the GUI (maybe hundreds of milliseconds).
The other option I was considering is to add simply an OnComUnknownChange event, togeher with the current OnComConnected and OnComDisconnected.
The good thing is that I have observed this behaviour only on one COM devices with errors. Actually this COM device is not even a COM device, but a mouse/keyboard, which my Windows identifies improperly.

3. Did not compile with fpc 3.2.4, fixed.

[mas steindorff]

I think I would have a single onComChange event call back fun() and pass "connected" or "disconnected" as the 1st parameter. A 2nd parameter which includes "unknown" can be expanded on later...
FYI mode: Depending on the PC dongle driver, I sometimes get some strange connect cycling with BT devices going in and out of range.  I think the driver was trying to say "reconnected" but my end was too simple to handle this new notification. I ended up closing the port and reopening it anyway (which worked). But this "new connect" trigged my code to re-download device mode setting so I would ended with more Comm traffic at a time when the connection was at it's weakest.
Mas