challenges using devices and stdin












1














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










share|improve this question









New contributor




sneiman is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • "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










  • 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
















1














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










share|improve this question









New contributor




sneiman is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • "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










  • 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














1












1








1







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










share|improve this question









New contributor




sneiman is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











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






share|improve this question









New contributor




sneiman is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




sneiman is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 2 days ago







sneiman













New contributor




sneiman is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked Jan 7 at 21:28









sneimansneiman

134




134




New contributor




sneiman is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





sneiman is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






sneiman is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












  • "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










  • 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












  • 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










1 Answer
1






active

oldest

votes


















0














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





share|improve this answer





















  • 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













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.










draft saved

draft discarded


















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









0














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





share|improve this answer





















  • 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


















0














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





share|improve this answer





















  • 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
















0












0








0






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





share|improve this answer












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






share|improve this answer












share|improve this answer



share|improve this answer










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




















  • 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












sneiman is a new contributor. Be nice, and check out our Code of Conduct.










draft saved

draft discarded


















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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

How to make a Squid Proxy server?

Is this a new Fibonacci Identity?

Touch on Surface Book