Dynamically-assign /dev/ttyUSB* using C++
up vote
0
down vote
favorite
I am running a custom C++ program on Raspbian that power cycles its USB ports every once in a while. However, I've noticed that the /dev/USB* enumeration is inconsistent between power cycles, and need to be able to handle this.
Are there any elegant ways to obtain a string such as "/dev/ttyUSB0" or "/dev/ttyUSB1" based on what's currently in /dev/? It's fair to assume there will only ever be one device connected, but it's not fair to assume what that device is aside from what's necessary for communication.
Things I've tried so far:
- dirent.h - seems clunky to grab all of "/dev/" and search for "ttyUSB"
- Forcing the USB device names to be static - I need my program to not be dependent on the device being used on the serial port
I'm not entirely-opposed to using system calls, but would like to avoid using "ls -l /dev/ttyUSB*" if possible.
c++ linux serial-port raspbian
asked Nov 19 at 19:55
Chris Mauer
566
add a comment |
up vote
0
down vote
favorite
I am running a custom C++ program on Raspbian that power cycles its USB ports every once in a while. However, I've noticed that the /dev/USB* enumeration is inconsistent between power cycles, and need to be able to handle this.
Are there any elegant ways to obtain a string such as "/dev/ttyUSB0" or "/dev/ttyUSB1" based on what's currently in /dev/? It's fair to assume there will only ever be one device connected, but it's not fair to assume what that device is aside from what's necessary for communication.
Things I've tried so far:
- dirent.h - seems clunky to grab all of "/dev/" and search for "ttyUSB"
- Forcing the USB device names to be static - I need my program to not be dependent on the device being used on the serial port
I'm not entirely-opposed to using system calls, but would like to avoid using "ls -l /dev/ttyUSB*" if possible.
c++ linux serial-port raspbian
asked Nov 19 at 19:55
Chris Mauer
566
You should use udev rule to define your device.
– tunglt
Nov 19 at 20:59
Unless I misunderstand something, that would require using device-specific information, which I would like to avoid due to the large number of devices this would need to support and maintain. I'd rather go the route of using an algorithm or library if possible.
– Chris Mauer
Nov 20 at 21:09
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I am running a custom C++ program on Raspbian that power cycles its USB ports every once in a while. However, I've noticed that the /dev/USB* enumeration is inconsistent between power cycles, and need to be able to handle this.
Are there any elegant ways to obtain a string such as "/dev/ttyUSB0" or "/dev/ttyUSB1" based on what's currently in /dev/? It's fair to assume there will only ever be one device connected, but it's not fair to assume what that device is aside from what's necessary for communication.
Things I've tried so far:
- dirent.h - seems clunky to grab all of "/dev/" and search for "ttyUSB"
- Forcing the USB device names to be static - I need my program to not be dependent on the device being used on the serial port
I'm not entirely-opposed to using system calls, but would like to avoid using "ls -l /dev/ttyUSB*" if possible.
c++ linux serial-port raspbian
asked Nov 19 at 19:55
Chris Mauer
566
I am running a custom C++ program on Raspbian that power cycles its USB ports every once in a while. However, I've noticed that the /dev/USB* enumeration is inconsistent between power cycles, and need to be able to handle this.
Are there any elegant ways to obtain a string such as "/dev/ttyUSB0" or "/dev/ttyUSB1" based on what's currently in /dev/? It's fair to assume there will only ever be one device connected, but it's not fair to assume what that device is aside from what's necessary for communication.
Things I've tried so far:
- dirent.h - seems clunky to grab all of "/dev/" and search for "ttyUSB"
- Forcing the USB device names to be static - I need my program to not be dependent on the device being used on the serial port
I'm not entirely-opposed to using system calls, but would like to avoid using "ls -l /dev/ttyUSB*" if possible.
c++ linux serial-port raspbian
c++ linux serial-port raspbian
asked Nov 19 at 19:55
Chris Mauer
566
asked Nov 19 at 19:55
Chris Mauer
566
asked Nov 19 at 19:55
Chris Mauer
566
asked Nov 19 at 19:55
Chris Mauer
566
asked Nov 19 at 19:55
Chris Mauer
566
566
You should use udev rule to define your device.
– tunglt
Nov 19 at 20:59
Unless I misunderstand something, that would require using device-specific information, which I would like to avoid due to the large number of devices this would need to support and maintain. I'd rather go the route of using an algorithm or library if possible.
– Chris Mauer
Nov 20 at 21:09
add a comment |
You should use udev rule to define your device.
– tunglt
Nov 19 at 20:59
Unless I misunderstand something, that would require using device-specific information, which I would like to avoid due to the large number of devices this would need to support and maintain. I'd rather go the route of using an algorithm or library if possible.
– Chris Mauer
Nov 20 at 21:09
You should use udev rule to define your device.
– tunglt
Nov 19 at 20:59
You should use udev rule to define your device.
– tunglt
Nov 19 at 20:59
Unless I misunderstand something, that would require using device-specific information, which I would like to avoid due to the large number of devices this would need to support and maintain. I'd rather go the route of using an algorithm or library if possible.
– Chris Mauer
Nov 20 at 21:09
Unless I misunderstand something, that would require using device-specific information, which I would like to avoid due to the large number of devices this would need to support and maintain. I'd rather go the route of using an algorithm or library if possible.
– Chris Mauer
Nov 20 at 21:09
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
The best way to do this is to create a udev rule that will create a symlink when the device is plugged in. Your udev rule will look something like this:
ATTRS{interface}="usb_converter", SYMLINK+="custom_link"
Note that there are many more options under ATTRS that you can use to match against a specific USB device. You can get information such as the PID/VID, serial number of the device, manu7facturer, etc. If your USB to serial converter is one made by FTDI, generally what I do is to use FTPROG to reprogram the device and give it a unique interface name(in this case, usb_converter) and then match off of that to ensure that it will always come up the same.
See this answer for more information, as well as this guide for writing udev rules.
answered Nov 20 at 14:58
rm5248
1,8811214
I think you misunderstood part of the question: "It's fair to assume there will only ever be one device connected, but it's not fair to assume what that device is aside from what's necessary for communication" There will be many different devices being plugged inserted into this, and I wanted to avoid the route of inserting device-specific information, such as the serial number/manufacturer/etc. I'm more interested in libraries and algorithms that will save me from having to maintain a large list of supported devices.
– Chris Mauer
Nov 20 at 21:04
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53381741%2fdynamically-assign-dev-ttyusb-using-c%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
The best way to do this is to create a udev rule that will create a symlink when the device is plugged in. Your udev rule will look something like this:
ATTRS{interface}="usb_converter", SYMLINK+="custom_link"
Note that there are many more options under ATTRS that you can use to match against a specific USB device. You can get information such as the PID/VID, serial number of the device, manu7facturer, etc. If your USB to serial converter is one made by FTDI, generally what I do is to use FTPROG to reprogram the device and give it a unique interface name(in this case, usb_converter) and then match off of that to ensure that it will always come up the same.
See this answer for more information, as well as this guide for writing udev rules.
answered Nov 20 at 14:58
rm5248
1,8811214
I think you misunderstood part of the question: "It's fair to assume there will only ever be one device connected, but it's not fair to assume what that device is aside from what's necessary for communication" There will be many different devices being plugged inserted into this, and I wanted to avoid the route of inserting device-specific information, such as the serial number/manufacturer/etc. I'm more interested in libraries and algorithms that will save me from having to maintain a large list of supported devices.
– Chris Mauer
Nov 20 at 21:04
add a comment |
up vote
0
down vote
The best way to do this is to create a udev rule that will create a symlink when the device is plugged in. Your udev rule will look something like this:
ATTRS{interface}="usb_converter", SYMLINK+="custom_link"
Note that there are many more options under ATTRS that you can use to match against a specific USB device. You can get information such as the PID/VID, serial number of the device, manu7facturer, etc. If your USB to serial converter is one made by FTDI, generally what I do is to use FTPROG to reprogram the device and give it a unique interface name(in this case, usb_converter) and then match off of that to ensure that it will always come up the same.
See this answer for more information, as well as this guide for writing udev rules.
answered Nov 20 at 14:58
rm5248
1,8811214
I think you misunderstood part of the question: "It's fair to assume there will only ever be one device connected, but it's not fair to assume what that device is aside from what's necessary for communication" There will be many different devices being plugged inserted into this, and I wanted to avoid the route of inserting device-specific information, such as the serial number/manufacturer/etc. I'm more interested in libraries and algorithms that will save me from having to maintain a large list of supported devices.
– Chris Mauer
Nov 20 at 21:04
add a comment |
up vote
0
down vote
up vote
0
down vote
The best way to do this is to create a udev rule that will create a symlink when the device is plugged in. Your udev rule will look something like this:
ATTRS{interface}="usb_converter", SYMLINK+="custom_link"
Note that there are many more options under ATTRS that you can use to match against a specific USB device. You can get information such as the PID/VID, serial number of the device, manu7facturer, etc. If your USB to serial converter is one made by FTDI, generally what I do is to use FTPROG to reprogram the device and give it a unique interface name(in this case, usb_converter) and then match off of that to ensure that it will always come up the same.
See this answer for more information, as well as this guide for writing udev rules.
answered Nov 20 at 14:58
rm5248
1,8811214
The best way to do this is to create a udev rule that will create a symlink when the device is plugged in. Your udev rule will look something like this:
ATTRS{interface}="usb_converter", SYMLINK+="custom_link"
Note that there are many more options under ATTRS that you can use to match against a specific USB device. You can get information such as the PID/VID, serial number of the device, manu7facturer, etc. If your USB to serial converter is one made by FTDI, generally what I do is to use FTPROG to reprogram the device and give it a unique interface name(in this case, usb_converter) and then match off of that to ensure that it will always come up the same.
See this answer for more information, as well as this guide for writing udev rules.
answered Nov 20 at 14:58
rm5248
1,8811214
answered Nov 20 at 14:58
rm5248
1,8811214
answered Nov 20 at 14:58
rm5248
1,8811214
answered Nov 20 at 14:58
rm5248
1,8811214
1,8811214
I think you misunderstood part of the question: "It's fair to assume there will only ever be one device connected, but it's not fair to assume what that device is aside from what's necessary for communication" There will be many different devices being plugged inserted into this, and I wanted to avoid the route of inserting device-specific information, such as the serial number/manufacturer/etc. I'm more interested in libraries and algorithms that will save me from having to maintain a large list of supported devices.
– Chris Mauer
Nov 20 at 21:04
add a comment |
I think you misunderstood part of the question: "It's fair to assume there will only ever be one device connected, but it's not fair to assume what that device is aside from what's necessary for communication" There will be many different devices being plugged inserted into this, and I wanted to avoid the route of inserting device-specific information, such as the serial number/manufacturer/etc. I'm more interested in libraries and algorithms that will save me from having to maintain a large list of supported devices.
– Chris Mauer
Nov 20 at 21:04
I think you misunderstood part of the question: "It's fair to assume there will only ever be one device connected, but it's not fair to assume what that device is aside from what's necessary for communication" There will be many different devices being plugged inserted into this, and I wanted to avoid the route of inserting device-specific information, such as the serial number/manufacturer/etc. I'm more interested in libraries and algorithms that will save me from having to maintain a large list of supported devices.
– Chris Mauer
Nov 20 at 21:04
I think you misunderstood part of the question: "It's fair to assume there will only ever be one device connected, but it's not fair to assume what that device is aside from what's necessary for communication" There will be many different devices being plugged inserted into this, and I wanted to avoid the route of inserting device-specific information, such as the serial number/manufacturer/etc. I'm more interested in libraries and algorithms that will save me from having to maintain a large list of supported devices.
– Chris Mauer
Nov 20 at 21:04
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53381741%2fdynamically-assign-dev-ttyusb-using-c%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
You should use udev rule to define your device.
– tunglt
Nov 19 at 20:59
Unless I misunderstand something, that would require using device-specific information, which I would like to avoid due to the large number of devices this would need to support and maintain. I'd rather go the route of using an algorithm or library if possible.
– Chris Mauer
Nov 20 at 21:09