Asio Serial ports: enumerating all the devices
Hello, Are there cross-platform methods to discover all the devices currently connected through serial ports with Boost? The idea is to have a function returning a list of device objects, each containing a handle, the related vendor id, product id and the baud rate at which the device was able to communicate. My knowledge of serial communication is very limited, may be it is technically infeasible. Do you have any thoughts for Boost or other libs? Analog enumerate method for HID devices: http://www.signal11.us/oss/hidapi/ Thanks, Vincent
The method that you linked works via Bluetooth and USB interfaces, which have mechanisms for device enumeration and capability discovery. RS-232 serial ports provide no such functionality; it's merely a pair of serial lines allowing for asynchronous data transfer in any direction. You could attempt to probe for specific devices, but you would need what amounts to a device driver for each type of device that you would want to support, instead of the standard, generic HID interfaces provided on USB/Bluetooth. Jason On 04/10/2013 08:40 AM, Vincent Boucher wrote:
Hello,
Are there cross-platform methods to discover all the devices currently connected through serial ports with Boost?
The idea is to have a function returning a list of device objects, each containing a handle, the related vendor id, product id and the baud rate at which the device was able to communicate.
My knowledge of serial communication is very limited, may be it is technically infeasible. Do you have any thoughts for Boost or other libs?
Analog enumerate method for HID devices: http://www.signal11.us/oss/hidapi/
Thanks,
Vincent
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
In my case, I have to address a serial over USB adapter. So, I would have to implement an OS-dependent method looping over all serial devices found (/dev/tty* or COM*), query them, wait for reply, then return a list of objects. Vincent On 10 Apr 2013, at 15:11, Jason Roehm wrote:
The method that you linked works via Bluetooth and USB interfaces, which have mechanisms for device enumeration and capability discovery. RS-232 serial ports provide no such functionality; it's merely a pair of serial lines allowing for asynchronous data transfer in any direction. You could attempt to probe for specific devices, but you would need what amounts to a device driver for each type of device that you would want to support, instead of the standard, generic HID interfaces provided on USB/Bluetooth.
Jason
On 04/10/2013 08:40 AM, Vincent Boucher wrote:
Hello,
Are there cross-platform methods to discover all the devices currently connected through serial ports with Boost?
The idea is to have a function returning a list of device objects, each containing a handle, the related vendor id, product id and the baud rate at which the device was able to communicate.
My knowledge of serial communication is very limited, may be it is technically infeasible. Do you have any thoughts for Boost or other libs?
Analog enumerate method for HID devices: http://www.signal11.us/oss/hidapi/
Thanks,
Vincent
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hello,
Are there cross-platform methods to discover all the devices currently connected through serial ports with Boost?
The idea is to have a function returning a list of device objects, each containing a handle, the related vendor id, product id and the baud rate at which the device was able to communicate.
My knowledge of serial communication is very limited, may be it is technically infeasible. Do you have any thoughts for Boost or other
On 04/10/2013, Vincent Boucher wrote: libs? It is technically infeasible. First of all, you would have to know the communication details (Baud rate, parity, stop bits and whatnot) in order to establish any kind of communication. Note that there is no feature in RS232 to find out these parameters. If you don't know them (mislaid your manual), you can only try to enumerate all possible combinations (which will be somewhere in the millions). Even worse, if you got the communication parameters right, there is no standard set of commands that can be sent. Some devices behave nicely and give you some sort of error message if they encounter a wrong command, but even that is vendor-specific. So even with the right communication parameters you might not recognize this unless you send the right command (I don't know whether there are any devices that only receive commands and never send answers, but in an infinitely large universe anything is possible ;-) On 04/10/2013, Vincent Boucher wrote:
In my case, I have to address a serial over USB adapter.
So, I would have to implement an OS-dependent method looping over all serial devices found (/dev/tty* or COM*), query them, wait for reply, then return a list of objects.
This only works if you know what you are looking for. Sometimes I have to do this when there are a lot of USB-RS232 adapters plugged in and I forgot which adapter was assigned which port number. Regards, Stuart
I don't know whether there are any devices that only receive commands and never send answers, but in an infinitely large universe anything is possible
There are......
My knowledge of serial communication is very limited,
You need to learn about it before you can do this sort of task. Provided you know the comms params (baud rate, parity, stop bits etc) and you know that your device does send responses to all commands you may be able to determine whether a specific device is present - possibly just by recognizing that *some* data has been returned. Unfortunately serial comms is a notoriously unstandardized field so this type of task is essentially impossible in the general case. (standards are so good everyone should have one ....) There is no built-in equivalent to TCP's ability to detect connection and disconnection, or SNMP's standard MIBs. Unhelpfully, Richard.
Thanks, I understand there's no other hope than preparing my device to answer to a custom poll message and checking the returned message (if any) to see if my device is connected. I guess that it might be harmful for some other devices that could mis-interpret my "poll" message or not handle it correctly. Vincent On 11 Apr 2013, at 17:00, Kerry, Richard wrote:
I don't know whether there are any devices that only receive commands and never send answers, but in an infinitely large universe anything is possible
There are......
My knowledge of serial communication is very limited,
You need to learn about it before you can do this sort of task.
Provided you know the comms params (baud rate, parity, stop bits etc) and you know that your device does send responses to all commands you may be able to determine whether a specific device is present - possibly just by recognizing that *some* data has been returned. Unfortunately serial comms is a notoriously unstandardized field so this type of task is essentially impossible in the general case. (standards are so good everyone should have one ....)
There is no built-in equivalent to TCP's ability to detect connection and disconnection, or SNMP's standard MIBs.
Unhelpfully, Richard.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
I guess that it might be harmful for some other devices that could mis-interpret my "poll" message or not handle it correctly.
Each type of device will have its own protocol/command set. If you try sending the same command to a variety of ports with unknown devices on them you could indeed cause problems. Consider if, in response to a command, say "abc123" : One device returns "I'm here" Another device formats all its disks and performs a Factory Reset ..... With serial control you need to know what you are talking to. Or at least you need to know the possible set of devices (ie protocols) you are talking to. Ideally you know in advance, via some sort of configuration. If you are in the position you appear to be, where you don't know, then you do at least need to know the set of possible devices/protocols, as you need to select suitable commands for polling. "preparing my device to answer to a custom poll message " Do you mean you are also in control of the embedded software within the device ? Ie that you are making hardware so can get this sorted out for your own purposes ? Or is this not so and you are dealing with existing serial devices ? Unhelpfully, Regards, Richard. BNCS Engineer. Ie my job is largely concerned with interfacing between PCs and a wide variety of manufacturers' devices. The devices may be on serial connections, or TCP, or UDP (eg SNMP) or other network connection, or sometimes GPIs. I think we have a few on USB. And some actually have their interface handled via a manufacturer-supplied library and API, so we don't see the hardware connection directly. For each protocol, or device type, we have a separate driver program. So it is necessary to know in advance what devices are to be controlled as we need to know what to run, and what address/port the device is connected to.
-----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Vincent Boucher Sent: 11 April 2013 16:28 To: boost-users@lists.boost.org Subject: Re: [Boost-users] Asio Serial ports: enumerating all the devices
Thanks, I understand there's no other hope than preparing my device to answer to a custom poll message and checking the returned message (if any) to see if my device is connected.
I guess that it might be harmful for some other devices that could mis-interpret my "poll" message or not handle it correctly.
Vincent
On 11 Apr 2013, at 17:00, Kerry, Richard wrote:
On 11 Apr 2013, at 17:44, Kerry, Richard wrote:
I guess that it might be harmful for some other devices that could mis-interpret my "poll" message or not handle it correctly.
Each type of device will have its own protocol/command set. If you try sending the same command to a variety of ports with unknown devices on them you could indeed cause problems. Consider if, in response to a command, say "abc123" : One device returns "I'm here" Another device formats all its disks and performs a Factory Reset .....
With serial control you need to know what you are talking to. Or at least you need to know the possible set of devices (ie protocols) you are talking to. Ideally you know in advance, via some sort of configuration. If you are in the position you appear to be, where you don't know, then you do at least need to know the set of possible devices/protocols, as you need to select suitable commands for polling.
"preparing my device to answer to a custom poll message " Do you mean you are also in control of the embedded software within the device ?
Ie that you are making hardware so can get this sorted out for your own purposes ? Or is this not so and you are dealing with existing serial devices ?
I could ask the hardware guys to implement such a response, but then it would be added to the firm/hardware in a further release, not now. My question is also about: if the OS can list the connected serial devices (when plugging and unplugging the device, the content of /dev is automatically updated) why Boost could not? Could Boost benefit of the updated /dev content? Of course such a list would not detail hardware info (such as baudrate) but at least would propagate device presence to user code. Also, could it be done in a cross platform manner?
Unhelpfully, Regards, Richard.
BNCS Engineer. Ie my job is largely concerned with interfacing between PCs and a wide variety of manufacturers' devices. The devices may be on serial connections, or TCP, or UDP (eg SNMP) or other network connection, or sometimes GPIs. I think we have a few on USB. And some actually have their interface handled via a manufacturer-supplied library and API, so we don't see the hardware connection directly. For each protocol, or device type, we have a separate driver program. So it is necessary to know in advance what devices are to be controlled as we need to know what to run, and what address/port the device is connected to.
-----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Vincent Boucher Sent: 11 April 2013 16:28 To: boost-users@lists.boost.org Subject: Re: [Boost-users] Asio Serial ports: enumerating all the devices
Thanks, I understand there's no other hope than preparing my device to answer to a custom poll message and checking the returned message (if any) to see if my device is connected.
I guess that it might be harmful for some other devices that could mis-interpret my "poll" message or not handle it correctly.
Vincent
On 11 Apr 2013, at 17:00, Kerry, Richard wrote:
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
I could ask the hardware guys to implement such a response, but then it would be added to the firm/hardware in a further release, not now.
So you are involved in designing hardware/embedded (ie your company is). Which implies you do have a restricted list of possible devices connected.
My question is also about: if the OS can list the connected serial devices (when plugging and unplugging the device, the content of /dev is automatically updated) why Boost could not? Could Boost benefit of the updated /dev content? Of course such a list would not detail hardware info (such as baudrate) but at least would propagate device presence to user code. Also, could it be done in a cross platform manner?
I work on Windows so I don't know about the cross-platform possibilities. Though I have to say I'd be surprised if *devices* appeared and disappeared automatically in /dev. I'd have expected there to be a list of *ports* which would appear there. If you're using network-connected serial ports (eg comtrol) then the collection there need not be fixed, but if your ports are part of your PC hardware then the number can't change (not without powering-down and opening it up). Just because you've got a port doesn't mean there's anything connected to it. And to get back anyting meaningful you need the baud rate etc. If you don't know that and it's set wrongly then you can sometimes get noise coming in that the serial port hardware thinks is data but there's nothing actually connected - or if the baud rate is set grossly wrong you can get data misinterpreted. If your company is in control of the connected devices does that mean you have standard settings for baud rate etc ? That would help. Do you mean that all the devices that could possibly be connected are from the same manufacturer ? (ie your company) Regards, Richard.
On 11 Apr 2013, at 18:10, Kerry, Richard wrote:
I could ask the hardware guys to implement such a response, but then it would be added to the firm/hardware in a further release, not now.
So you are involved in designing hardware/embedded (ie your company is). Which implies you do have a restricted list of possible devices connected.
In a general manner, the end-user could potentially have (any) other serial devices connected, and we don't have control on them.
My question is also about: if the OS can list the connected serial devices (when plugging and unplugging the device, the content of /dev is automatically updated) why Boost could not? Could Boost benefit of the updated /dev content? Of course such a list would not detail hardware info (such as baudrate) but at least would propagate device presence to user code. Also, could it be done in a cross platform manner?
I work on Windows so I don't know about the cross-platform possibilities. Though I have to say I'd be surprised if *devices* appeared and disappeared automatically in /dev. I'd have expected there to be a list of *ports* which would appear there. If you're using network-connected serial ports (eg comtrol) then the collection there need not be fixed, but if your ports are part of your PC hardware then the number can't change (not without powering-down and opening it up). Just because you've got a port doesn't mean there's anything connected to it.
And to get back anyting meaningful you need the baud rate etc. If you don't know that and it's set wrongly then you can sometimes get noise coming in that the serial port hardware thinks is data but there's nothing actually connected - or if the baud rate is set grossly wrong you can get data misinterpreted. If your company is in control of the connected devices does that mean you have standard settings for baud rate etc ? That would help. Do you mean that all the devices that could possibly be connected are from the same manufacturer ? (ie your company)
The Boost software I'm going to write should be stable enough for end-users even if our device XYZ is not connected but another ZZZ (incompatible) is found. It should gracely says "cannot find device XYZ". Or it should be able to connect to XYZ if both (XYZ and ZZZ) are connected and my device XYZ is located at an "unusual" port number (COM2 or 5 ...). Regards, Vincent
Regards, Richard.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Vincent, Please can you make absolutely clear to us whether you are asking about serial ports, or serially-connected devices ? (The serial ports themselves may be integral parts of the computer, or they may be accessed via USB, or Ethernet, or some other means) The OS can know about serial ports - indeed I think it has to. I think this is what is present in /dev. (if this is not so please can someone with Linux knowledge elaborate) There is no way the OS can know about the serially-connected devices. And no way of guaranteeing you can safely query devices. When you meet a person you've never met before, and who speaks another language, you may think you are offering a respectful greeting, but the other person may hear an insult against his mother.... When you send your query message to a serially-connected device where you don't know what messages the device understands you may think you are saying "are you there ?" but the device may hear "launch the missiles". I leave it to you and your lawyers to consider whether you can accept this risk. But if what you mean is serial ports, then all this is moot, and the OS can know, and ASIO might be able to enumerate them for you. Helpfully, Hopeully, Richard. [Blue line] Richard Kerry BNCS Engineer T: +44 (0)20 82259063[cid:6E3BCE2-237A-4FADD-BB94-96842E0282@MimeCtl]about:blank# M: +44 (0)7812 325518[cid:6E3BCE2-237A-4FADD-BB94-96842E0282@MimeCtl]about:blank# Room EBX 301, BBC Television Centre, Wood Lane, London, W12 7RJ richard.kerry@atos.nethttps://webmail.siemens-it-solutions.com/owa/redir.aspx?C=9fb20d019e3e4cb99344d708709a3177&URL=mailto%3arichard.kerry%40atos.net uk.atos.nethttps://webmail.siemens-it-solutions.com/owa/redir.aspx?C=9fb20d019e3e4cb99344d708709a3177&URL=http%3a%2f%2fuk.atos.net%2fen-uk%2f [Atos logo] This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable ________________________________ From: Boost-users [boost-users-bounces@lists.boost.org] on behalf of Vincent Boucher [vin.boucher@gmail.com] Sent: 11 April 2013 17:21 To: boost-users@lists.boost.org Subject: Re: [Boost-users] Asio Serial ports: enumerating all the devices On 11 Apr 2013, at 18:10, Kerry, Richard wrote:
I could ask the hardware guys to implement such a response, but then it would be added to the firm/hardware in a further release, not now.
So you are involved in designing hardware/embedded (ie your company is). Which implies you do have a restricted list of possible devices connected.
In a general manner, the end-user could potentially have (any) other serial devices connected, and we don't have control on them.
My question is also about: if the OS can list the connected serial devices (when plugging and unplugging the device, the content of /dev is automatically updated) why Boost could not? Could Boost benefit of the updated /dev content? Of course such a list would not detail hardware info (such as baudrate) but at least would propagate device presence to user code. Also, could it be done in a cross platform manner?
I work on Windows so I don't know about the cross-platform possibilities. Though I have to say I'd be surprised if *devices* appeared and disappeared automatically in /dev. I'd have expected there to be a list of *ports* which would appear there. If you're using network-connected serial ports (eg comtrol) then the collection there need not be fixed, but if your ports are part of your PC hardware then the number can't change (not without powering-down and opening it up). Just because you've got a port doesn't mean there's anything connected to it.
And to get back anyting meaningful you need the baud rate etc. If you don't know that and it's set wrongly then you can sometimes get noise coming in that the serial port hardware thinks is data but there's nothing actually connected - or if the baud rate is set grossly wrong you can get data misinterpreted. If your company is in control of the connected devices does that mean you have standard settings for baud rate etc ? That would help. Do you mean that all the devices that could possibly be connected are from the same manufacturer ? (ie your company)
The Boost software I'm going to write should be stable enough for end-users even if our device XYZ is not connected but another ZZZ (incompatible) is found. It should gracely says "cannot find device XYZ". Or it should be able to connect to XYZ if both (XYZ and ZZZ) are connected and my device XYZ is located at an "unusual" port number (COM2 or 5 ...). Regards, Vincent
Regards, Richard.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
"vendor id, product id " What's that ? I mean for a serial device. If they are present in the device protocol then fine, but that depends on the individual devices and their protocols. You can check whether there has been any traffic, which might be useful, but serial connections are just streams of bytes. Unhelpfully, Richard. PS I do recognize "vendor id, product id " for SNMP and for other protocols working at a higher level than "serial". ________________________________ From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Vincent Boucher Sent: 10 April 2013 13:40 To: boost-users@lists.boost.org Subject: [Boost-users] Asio Serial ports: enumerating all the devices Hello, Are there cross-platform methods to discover all the devices currently connected through serial ports with Boost? The idea is to have a function returning a list of device objects, each containing a handle, the related vendor id, product id and the baud rate at which the device was able to communicate. My knowledge of serial communication is very limited, may be it is technically infeasible. Do you have any thoughts for Boost or other libs? Analog enumerate method for HID devices: http://www.signal11.us/oss/hidapi/ Thanks, Vincent
"vendor id, product id " What's that ? I mean for a serial device. If they are present in the device protocol then fine, but that depends on the individual devices and their protocols. You can check whether there has been any traffic, which might be useful, but serial connections are just streams of bytes.
I think the OP might be mixing up serial-bridges with the actual bridged serial devices. E.g. FTDI-bridges have a Vendor-ID, Product-ID pair which can be used to identify bridged serial devices, if you assign special values. However, only their proprietary drivers (d2xx) allow enumerating the bridges attached to the PC. So there is no cross-platform or even a cross-vendor way to do that. However, if you know that your devices are FTDI-bridges and you happen to work on OS's with driver support, then you can bypass the virtual serial ports alltogether and identify/enumerate/communicate with the devices (I'm not too sure if the d2xx-drivers hand out handles that you can use with the usual OS file API though). Regards, Michael
Yes, quite possibly. That's quite close to what I was trying to say with respect to the /dev contents. All that is probably possible would be to enumerate is serial interfaces (COM ports, in Windows parlance). Or to enumerate all devices then somehow query them for their type to ascertain that they are serial ports. There's no way to determine the connected devices. A quick Google search tells me FTDI devices are serial-ports accessed via USB. ComTrol devices are similar in that they are serial ports accessed via Ethernet. I guess there are other ways of making a serial port available. Regards, Richard. [Blue line] Richard Kerry BNCS Engineer T: +44 (0)20 82259063[cid:C7E1BD7-D3AC-46FDD-B9D9-2FB8095547@MimeCtl]about:blank# M: +44 (0)7812 325518[cid:C7E1BD7-D3AC-46FDD-B9D9-2FB8095547@MimeCtl]about:blank# Room EBX 301, BBC Television Centre, Wood Lane, London, W12 7RJ richard.kerry@atos.nethttps://webmail.siemens-it-solutions.com/owa/redir.aspx?C=9fb20d019e3e4cb99344d708709a3177&URL=mailto%3arichard.kerry%40atos.net uk.atos.nethttps://webmail.siemens-it-solutions.com/owa/redir.aspx?C=9fb20d019e3e4cb99344d708709a3177&URL=http%3a%2f%2fuk.atos.net%2fen-uk%2f [Atos logo] This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable ________________________________ From: Boost-users [boost-users-bounces@lists.boost.org] on behalf of Michael Steinberg [michael.steinberg@tu-clausthal.de] Sent: 11 April 2013 19:17 To: boost-users@lists.boost.org Subject: Re: [Boost-users] Asio Serial ports: enumerating all the devices "vendor id, product id " What's that ? I mean for a serial device. If they are present in the device protocol then fine, but that depends on the individual devices and their protocols. You can check whether there has been any traffic, which might be useful, but serial connections are just streams of bytes. I think the OP might be mixing up serial-bridges with the actual bridged serial devices. E.g. FTDI-bridges have a Vendor-ID, Product-ID pair which can be used to identify bridged serial devices, if you assign special values. However, only their proprietary drivers (d2xx) allow enumerating the bridges attached to the PC. So there is no cross-platform or even a cross-vendor way to do that. However, if you know that your devices are FTDI-bridges and you happen to work on OS's with driver support, then you can bypass the virtual serial ports alltogether and identify/enumerate/communicate with the devices (I'm not too sure if the d2xx-drivers hand out handles that you can use with the usual OS file API though). Regards, Michael
participants (5)
-
Jason Roehm -
Kerry, Richard -
Michael Steinberg -
Stuart -
Vincent Boucher