challenges using devices and stdin
I am using an embedded ubuntu based processor as a machine vision system. It communicates over 2 serial ports with an associated flight controller.
My problem was that normal open(), close() calls supporting the vision<->flight controller communications caused stdin calls (fgets(), scanf(), etc) to fail in peculiar ways - the calls thought there was input, but there wasn't, and the returned buffer was garbage.
I originally thought this was due to conflicts between the kernel's default text console and my use of the serial devices. After a circuitous search, I realized this was incorrect - I found a subtle bug that caused the device file descriptor to be set to 0 - same as stdin - under some circumstances.
I found this bug by following up a lead from roamina below. I have left his answer as accepted because he set me on the trail to the real problem.
Comments below do have some useful info for others with concerns about devices, stdin, and the default text console.
thanks
linux ubuntu serial-console
New contributor
|
show 2 more comments
I am using an embedded ubuntu based processor as a machine vision system. It communicates over 2 serial ports with an associated flight controller.
My problem was that normal open(), close() calls supporting the vision<->flight controller communications caused stdin calls (fgets(), scanf(), etc) to fail in peculiar ways - the calls thought there was input, but there wasn't, and the returned buffer was garbage.
I originally thought this was due to conflicts between the kernel's default text console and my use of the serial devices. After a circuitous search, I realized this was incorrect - I found a subtle bug that caused the device file descriptor to be set to 0 - same as stdin - under some circumstances.
I found this bug by following up a lead from roamina below. I have left his answer as accepted because he set me on the trail to the real problem.
Comments below do have some useful info for others with concerns about devices, stdin, and the default text console.
thanks
linux ubuntu serial-console
New contributor
"Reading suggests thatstty
sets stdin to the port being configured" - not in my experience. What should happen is thatstty
configures the line attached to its stdin. I've also known systems reset the line characteristics when all file descriptors to that device are closed (effectively negating a naivestty ... </dev/ttyXX
but I have no way of confirming if that also applies to Linux-based systems.
– roaima
Jan 7 at 21:44
roaima's comment regarding stdin being set seem correct to me. I took my interpretation from man stty - but it clearly says something different than my original interpretation. I have edited question to avoid confusion.
– sneiman
Jan 7 at 22:47
well - the problem is actually very different from the question I asked. I figured it out by taking a look at the link roaima noted. It led me on a path that made me realize that there was actually NO tty issue - the problem was a subtle bug that was resetting the open fd to 0. my bad. thank you roaima for sticking with me.
– sneiman
2 days ago
For those with similar problems: under almost all circumstance the fd for stdin is 0. open() should return a different fd for a legitimately configured open call. If it doesn't, you either closed fd 0, or have a bug that is incorrectly using 0 as fd.
– sneiman
2 days ago
Finally, the default console is set int the kernel command line. You can view this typically at /proc/cmdline. Changing it depends on what version of linux you are on, If I knew them all I would list them - if you need to sort it out, search for 'kernel command line' and read the details for your version of linux.
– sneiman
2 days ago
|
show 2 more comments
I am using an embedded ubuntu based processor as a machine vision system. It communicates over 2 serial ports with an associated flight controller.
My problem was that normal open(), close() calls supporting the vision<->flight controller communications caused stdin calls (fgets(), scanf(), etc) to fail in peculiar ways - the calls thought there was input, but there wasn't, and the returned buffer was garbage.
I originally thought this was due to conflicts between the kernel's default text console and my use of the serial devices. After a circuitous search, I realized this was incorrect - I found a subtle bug that caused the device file descriptor to be set to 0 - same as stdin - under some circumstances.
I found this bug by following up a lead from roamina below. I have left his answer as accepted because he set me on the trail to the real problem.
Comments below do have some useful info for others with concerns about devices, stdin, and the default text console.
thanks
linux ubuntu serial-console
New contributor
I am using an embedded ubuntu based processor as a machine vision system. It communicates over 2 serial ports with an associated flight controller.
My problem was that normal open(), close() calls supporting the vision<->flight controller communications caused stdin calls (fgets(), scanf(), etc) to fail in peculiar ways - the calls thought there was input, but there wasn't, and the returned buffer was garbage.
I originally thought this was due to conflicts between the kernel's default text console and my use of the serial devices. After a circuitous search, I realized this was incorrect - I found a subtle bug that caused the device file descriptor to be set to 0 - same as stdin - under some circumstances.
I found this bug by following up a lead from roamina below. I have left his answer as accepted because he set me on the trail to the real problem.
Comments below do have some useful info for others with concerns about devices, stdin, and the default text console.
thanks
linux ubuntu serial-console
linux ubuntu serial-console
New contributor
New contributor
edited 2 days ago
sneiman
New contributor
asked Jan 7 at 21:28
sneimansneiman
134
134
New contributor
New contributor
"Reading suggests thatstty
sets stdin to the port being configured" - not in my experience. What should happen is thatstty
configures the line attached to its stdin. I've also known systems reset the line characteristics when all file descriptors to that device are closed (effectively negating a naivestty ... </dev/ttyXX
but I have no way of confirming if that also applies to Linux-based systems.
– roaima
Jan 7 at 21:44
roaima's comment regarding stdin being set seem correct to me. I took my interpretation from man stty - but it clearly says something different than my original interpretation. I have edited question to avoid confusion.
– sneiman
Jan 7 at 22:47
well - the problem is actually very different from the question I asked. I figured it out by taking a look at the link roaima noted. It led me on a path that made me realize that there was actually NO tty issue - the problem was a subtle bug that was resetting the open fd to 0. my bad. thank you roaima for sticking with me.
– sneiman
2 days ago
For those with similar problems: under almost all circumstance the fd for stdin is 0. open() should return a different fd for a legitimately configured open call. If it doesn't, you either closed fd 0, or have a bug that is incorrectly using 0 as fd.
– sneiman
2 days ago
Finally, the default console is set int the kernel command line. You can view this typically at /proc/cmdline. Changing it depends on what version of linux you are on, If I knew them all I would list them - if you need to sort it out, search for 'kernel command line' and read the details for your version of linux.
– sneiman
2 days ago
|
show 2 more comments
"Reading suggests thatstty
sets stdin to the port being configured" - not in my experience. What should happen is thatstty
configures the line attached to its stdin. I've also known systems reset the line characteristics when all file descriptors to that device are closed (effectively negating a naivestty ... </dev/ttyXX
but I have no way of confirming if that also applies to Linux-based systems.
– roaima
Jan 7 at 21:44
roaima's comment regarding stdin being set seem correct to me. I took my interpretation from man stty - but it clearly says something different than my original interpretation. I have edited question to avoid confusion.
– sneiman
Jan 7 at 22:47
well - the problem is actually very different from the question I asked. I figured it out by taking a look at the link roaima noted. It led me on a path that made me realize that there was actually NO tty issue - the problem was a subtle bug that was resetting the open fd to 0. my bad. thank you roaima for sticking with me.
– sneiman
2 days ago
For those with similar problems: under almost all circumstance the fd for stdin is 0. open() should return a different fd for a legitimately configured open call. If it doesn't, you either closed fd 0, or have a bug that is incorrectly using 0 as fd.
– sneiman
2 days ago
Finally, the default console is set int the kernel command line. You can view this typically at /proc/cmdline. Changing it depends on what version of linux you are on, If I knew them all I would list them - if you need to sort it out, search for 'kernel command line' and read the details for your version of linux.
– sneiman
2 days ago
"Reading suggests that
stty
sets stdin to the port being configured" - not in my experience. What should happen is that stty
configures the line attached to its stdin. I've also known systems reset the line characteristics when all file descriptors to that device are closed (effectively negating a naive stty ... </dev/ttyXX
but I have no way of confirming if that also applies to Linux-based systems.– roaima
Jan 7 at 21:44
"Reading suggests that
stty
sets stdin to the port being configured" - not in my experience. What should happen is that stty
configures the line attached to its stdin. I've also known systems reset the line characteristics when all file descriptors to that device are closed (effectively negating a naive stty ... </dev/ttyXX
but I have no way of confirming if that also applies to Linux-based systems.– roaima
Jan 7 at 21:44
roaima's comment regarding stdin being set seem correct to me. I took my interpretation from man stty - but it clearly says something different than my original interpretation. I have edited question to avoid confusion.
– sneiman
Jan 7 at 22:47
roaima's comment regarding stdin being set seem correct to me. I took my interpretation from man stty - but it clearly says something different than my original interpretation. I have edited question to avoid confusion.
– sneiman
Jan 7 at 22:47
well - the problem is actually very different from the question I asked. I figured it out by taking a look at the link roaima noted. It led me on a path that made me realize that there was actually NO tty issue - the problem was a subtle bug that was resetting the open fd to 0. my bad. thank you roaima for sticking with me.
– sneiman
2 days ago
well - the problem is actually very different from the question I asked. I figured it out by taking a look at the link roaima noted. It led me on a path that made me realize that there was actually NO tty issue - the problem was a subtle bug that was resetting the open fd to 0. my bad. thank you roaima for sticking with me.
– sneiman
2 days ago
For those with similar problems: under almost all circumstance the fd for stdin is 0. open() should return a different fd for a legitimately configured open call. If it doesn't, you either closed fd 0, or have a bug that is incorrectly using 0 as fd.
– sneiman
2 days ago
For those with similar problems: under almost all circumstance the fd for stdin is 0. open() should return a different fd for a legitimately configured open call. If it doesn't, you either closed fd 0, or have a bug that is incorrectly using 0 as fd.
– sneiman
2 days ago
Finally, the default console is set int the kernel command line. You can view this typically at /proc/cmdline. Changing it depends on what version of linux you are on, If I knew them all I would list them - if you need to sort it out, search for 'kernel command line' and read the details for your version of linux.
– sneiman
2 days ago
Finally, the default console is set int the kernel command line. You can view this typically at /proc/cmdline. Changing it depends on what version of linux you are on, If I knew them all I would list them - if you need to sort it out, search for 'kernel command line' and read the details for your version of linux.
– sneiman
2 days ago
|
show 2 more comments
1 Answer
1
active
oldest
votes
If all you want to do is to set the terminal line characteristics and have them stick, try this
# Serial line
tty=/dev/ttyS1
# Open the serial port and hold it open
sleep 300 <$tty &
slpid=$!
# Set the characteristics and run the serial port code
stty 19200... <$tty
/run/your/program
# Clean up
kill $slpid 2>/dev/null
Thanks for this. It works of course, but is not my actual problem. The more I think about it, I think the kernel has stolen /dev/ttyS2 for its default text console, and I just have to figure out how to change that. There are no grub files unfortunately. I am going to close the question, and ask a better one, unless you object. seth
– sneiman
Jan 8 at 0:21
@sneiman the Ubuntu Serial Console Howto explains the steps to activate a serial console. It might be worth checking that to see if your embedded system already has it enabled, and if so what steps you can take to disable it.
– roaima
2 days ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
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',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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
});
}
});
sneiman is a new contributor. Be nice, and check out our Code of Conduct.
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%2funix.stackexchange.com%2fquestions%2f493094%2fchallenges-using-devices-and-stdin%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
If all you want to do is to set the terminal line characteristics and have them stick, try this
# Serial line
tty=/dev/ttyS1
# Open the serial port and hold it open
sleep 300 <$tty &
slpid=$!
# Set the characteristics and run the serial port code
stty 19200... <$tty
/run/your/program
# Clean up
kill $slpid 2>/dev/null
Thanks for this. It works of course, but is not my actual problem. The more I think about it, I think the kernel has stolen /dev/ttyS2 for its default text console, and I just have to figure out how to change that. There are no grub files unfortunately. I am going to close the question, and ask a better one, unless you object. seth
– sneiman
Jan 8 at 0:21
@sneiman the Ubuntu Serial Console Howto explains the steps to activate a serial console. It might be worth checking that to see if your embedded system already has it enabled, and if so what steps you can take to disable it.
– roaima
2 days ago
add a comment |
If all you want to do is to set the terminal line characteristics and have them stick, try this
# Serial line
tty=/dev/ttyS1
# Open the serial port and hold it open
sleep 300 <$tty &
slpid=$!
# Set the characteristics and run the serial port code
stty 19200... <$tty
/run/your/program
# Clean up
kill $slpid 2>/dev/null
Thanks for this. It works of course, but is not my actual problem. The more I think about it, I think the kernel has stolen /dev/ttyS2 for its default text console, and I just have to figure out how to change that. There are no grub files unfortunately. I am going to close the question, and ask a better one, unless you object. seth
– sneiman
Jan 8 at 0:21
@sneiman the Ubuntu Serial Console Howto explains the steps to activate a serial console. It might be worth checking that to see if your embedded system already has it enabled, and if so what steps you can take to disable it.
– roaima
2 days ago
add a comment |
If all you want to do is to set the terminal line characteristics and have them stick, try this
# Serial line
tty=/dev/ttyS1
# Open the serial port and hold it open
sleep 300 <$tty &
slpid=$!
# Set the characteristics and run the serial port code
stty 19200... <$tty
/run/your/program
# Clean up
kill $slpid 2>/dev/null
If all you want to do is to set the terminal line characteristics and have them stick, try this
# Serial line
tty=/dev/ttyS1
# Open the serial port and hold it open
sleep 300 <$tty &
slpid=$!
# Set the characteristics and run the serial port code
stty 19200... <$tty
/run/your/program
# Clean up
kill $slpid 2>/dev/null
answered Jan 7 at 23:02
roaimaroaima
43.1k553116
43.1k553116
Thanks for this. It works of course, but is not my actual problem. The more I think about it, I think the kernel has stolen /dev/ttyS2 for its default text console, and I just have to figure out how to change that. There are no grub files unfortunately. I am going to close the question, and ask a better one, unless you object. seth
– sneiman
Jan 8 at 0:21
@sneiman the Ubuntu Serial Console Howto explains the steps to activate a serial console. It might be worth checking that to see if your embedded system already has it enabled, and if so what steps you can take to disable it.
– roaima
2 days ago
add a comment |
Thanks for this. It works of course, but is not my actual problem. The more I think about it, I think the kernel has stolen /dev/ttyS2 for its default text console, and I just have to figure out how to change that. There are no grub files unfortunately. I am going to close the question, and ask a better one, unless you object. seth
– sneiman
Jan 8 at 0:21
@sneiman the Ubuntu Serial Console Howto explains the steps to activate a serial console. It might be worth checking that to see if your embedded system already has it enabled, and if so what steps you can take to disable it.
– roaima
2 days ago
Thanks for this. It works of course, but is not my actual problem. The more I think about it, I think the kernel has stolen /dev/ttyS2 for its default text console, and I just have to figure out how to change that. There are no grub files unfortunately. I am going to close the question, and ask a better one, unless you object. seth
– sneiman
Jan 8 at 0:21
Thanks for this. It works of course, but is not my actual problem. The more I think about it, I think the kernel has stolen /dev/ttyS2 for its default text console, and I just have to figure out how to change that. There are no grub files unfortunately. I am going to close the question, and ask a better one, unless you object. seth
– sneiman
Jan 8 at 0:21
@sneiman the Ubuntu Serial Console Howto explains the steps to activate a serial console. It might be worth checking that to see if your embedded system already has it enabled, and if so what steps you can take to disable it.
– roaima
2 days ago
@sneiman the Ubuntu Serial Console Howto explains the steps to activate a serial console. It might be worth checking that to see if your embedded system already has it enabled, and if so what steps you can take to disable it.
– roaima
2 days ago
add a comment |
sneiman is a new contributor. Be nice, and check out our Code of Conduct.
sneiman is a new contributor. Be nice, and check out our Code of Conduct.
sneiman is a new contributor. Be nice, and check out our Code of Conduct.
sneiman is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- 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%2funix.stackexchange.com%2fquestions%2f493094%2fchallenges-using-devices-and-stdin%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
"Reading suggests that
stty
sets stdin to the port being configured" - not in my experience. What should happen is thatstty
configures the line attached to its stdin. I've also known systems reset the line characteristics when all file descriptors to that device are closed (effectively negating a naivestty ... </dev/ttyXX
but I have no way of confirming if that also applies to Linux-based systems.– roaima
Jan 7 at 21:44
roaima's comment regarding stdin being set seem correct to me. I took my interpretation from man stty - but it clearly says something different than my original interpretation. I have edited question to avoid confusion.
– sneiman
Jan 7 at 22:47
well - the problem is actually very different from the question I asked. I figured it out by taking a look at the link roaima noted. It led me on a path that made me realize that there was actually NO tty issue - the problem was a subtle bug that was resetting the open fd to 0. my bad. thank you roaima for sticking with me.
– sneiman
2 days ago
For those with similar problems: under almost all circumstance the fd for stdin is 0. open() should return a different fd for a legitimately configured open call. If it doesn't, you either closed fd 0, or have a bug that is incorrectly using 0 as fd.
– sneiman
2 days ago
Finally, the default console is set int the kernel command line. You can view this typically at /proc/cmdline. Changing it depends on what version of linux you are on, If I knew them all I would list them - if you need to sort it out, search for 'kernel command line' and read the details for your version of linux.
– sneiman
2 days ago