LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 07-22-2013, 01:37 PM   #1
henryyao
LQ Newbie
 
Registered: Jul 2013
Posts: 23

Rep: Reputation: 0
will printf() conflict with the 232 serial communcation in embedded linux system?


I'm having an embedded linux device. I'm using ttyO2 as my console. However, at the same time my MCU need to perform RS232 communicate with a device through ttyO2.

Now lets say if the MCU and the device are communicating, and I type some characters in the console terminal, or there runs another thread that will invoke function printf() , will that conflicts with the 232 communication? is the printf() outputting to the ttyO2?
thanks
 
Old 07-22-2013, 02:19 PM   #2
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,654

Rep: Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255
It depends. If you are using stdin/stdout/stderr as normal, then no, it will not affect any output to a fourth file descriptor attached to /dev/tty02. If you have redirected any of these to /dev/tty02, then yes, it could.

What can cause problems is if your file is opened to /dev/tty02 as a buffered file (using fopen). It can work, but you have to remember that since you are writing into a buffer, and not attached to a normal terminal; it will not necessarily flush output. It is usually easier to handle with open/read/write/close (which are unbuffered) than fopen/fread/fprint/fwrite/fclose functions (which are buffered).
 
Old 08-22-2013, 04:18 PM   #3
henryyao
LQ Newbie
 
Registered: Jul 2013
Posts: 23

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by jpollard View Post
It depends. If you are using stdin/stdout/stderr as normal, then no, it will not affect any output to a fourth file descriptor attached to /dev/tty02. If you have redirected any of these to /dev/tty02, then yes, it could.

What can cause problems is if your file is opened to /dev/tty02 as a buffered file (using fopen). It can work, but you have to remember that since you are writing into a buffer, and not attached to a normal terminal; it will not necessarily flush output. It is usually easier to handle with open/read/write/close (which are unbuffered) than fopen/fread/fprint/fwrite/fclose functions (which are buffered).
1)So you are saying for each /dev/ttyOx, there might be lots of file descriptors attached to it, and there will be no conflicts between them?
2)I dont understand what did you mean by " If you have redirected any of these to /dev/tty02, then yes, it could." Shouldn't the stdin/stdout/stderr directed to the console by default? Since I'm setting ttyO2 as my console, there will be for sure conflicts?
 
Old 08-22-2013, 04:38 PM   #4
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,654

Rep: Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255
Quote:
Originally Posted by henryyao View Post
1)So you are saying for each /dev/ttyOx, there might be lots of file descriptors attached to it, and there will be no conflicts between them?
Yes, there could be lots. If the console is redirected there, you have kernel messages, syslog message. If you have your command terminal there, then you have stdin/stdout/stderr.

Normally, there is no interference, but there could be. It depends on what else is trying to attach.
Quote:

2)I dont understand what did you mean by " If you have redirected any of these to /dev/tty02, then yes, it could." Shouldn't the stdin/stdout/stderr directed to the console by default? Since I'm setting ttyO2 as my console, there will be for sure conflicts?
Since this is ALSO attached to an embedded device, you may get all kinds of problems depending on how the device handles a serial line. Modem signals? (cts/rts) start/stop (ctrl-s/ctrl-q) both, neither? who sets the baud rate? how does the device detect the baud rate? how does the redirected console detect/set the baud rate...

Normally, the console is NOT assigned to the same serial device that is connected to an embedded device... unless that embedded device is a terminal. This is because embedded devices tend to have special commands/control signals used to direct its performance. Mixing console I/O and such signals usually just fails...
 
Old 08-22-2013, 06:35 PM   #5
henryyao
LQ Newbie
 
Registered: Jul 2013
Posts: 23

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by jpollard View Post
Yes, there could be lots. If the console is redirected there, you have kernel messages, syslog message. If you have your command terminal there, then you have stdin/stdout/stderr.

Normally, there is no interference, but there could be. It depends on what else is trying to attach.


Since this is ALSO attached to an embedded device, you may get all kinds of problems depending on how the device handles a serial line. Modem signals? (cts/rts) start/stop (ctrl-s/ctrl-q) both, neither? who sets the baud rate? how does the device detect the baud rate? how does the redirected console detect/set the baud rate...

Normally, the console is NOT assigned to the same serial device that is connected to an embedded device... unless that embedded device is a terminal. This is because embedded devices tend to have special commands/control signals used to direct its performance. Mixing console I/O and such signals usually just fails...
Ok I see. quite clear, thanks
still two more question:
1.when we type a command in the terminal, for example, "ls" or "cd /home", these commands(some are shell commands some are not) go in to the stdin, dont they? And the response of those command goes to the stdout, correct? But what's the program that keeps reading from the stdin and dephrase our commands.

2. I do not understand what is a console. It seems like a terminal for me, just that the terminal and the console handle different types of data. for example, the console will deal with the system log and stuff while terminal deal with stdinout? Or we can say that the difference is console use printk() while the terminal use printf()?

Last edited by henryyao; 08-22-2013 at 06:37 PM.
 
Old 08-23-2013, 10:57 AM   #6
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,654

Rep: Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255
Quote:
Originally Posted by henryyao View Post
Ok I see. quite clear, thanks
still two more question:
1.when we type a command in the terminal, for example, "ls" or "cd /home", these commands(some are shell commands some are not) go in to the stdin, dont they? And the response of those command goes to the stdout, correct? But what's the program that keeps reading from the stdin and dephrase our commands.
That depends. It starts with the shell, which has stdin/stdout/stderr all going to the same device (3 connections). When a command is typed in, stdin, stdout AND stderr are normally passed to it (now there are 6 connections). What the program STARTED with this configuration does with stdin/stdout/stderr depends on the program. Consider an editor... editors tend to turn off all character interpretation (and buffering) so that they can interpret any escape sequences, interrupt signals, and normal character sequences. The editor decides what is echoed back to stdout bypassing any interpretation by the system.

SOME programs (such as passwd) don't even use stdin/stdout - instead they open a new channel via /dev/tty (which is associated with the control terminal) so that they can handle password input and any prompts themselves. stderr might only be used for error messages, but it can also be considered a security issue, so they could even use the private channel for that.

Other programs (such as ssh) turn off everything, and pass the terminal type to the remote system... at this point, what is communicated with stdin/out/err is totally under the control of the remote system.

Quote:
2. I do not understand what is a console. It seems like a terminal for me, just that the terminal and the console handle different types of data. for example, the console will deal with the system log and stuff while terminal deal with stdinout? Or we can say that the difference is console use printk() while the terminal use printf()?
The definition varies depending on the context.

From the kernels point of view the console is pseudo device /dev/console, which is usually redirected to a virtual terminal. Outputs of the kernel printk go to /dev/console, which is then redirected to a real terminal like device, or to a log queue, or both.

From a user point of view it is the command line interpreter used to input commands and receive output.

Usually embedded devices that are attached to serial devices do not have that serial device treated as a console (of any context). There are just too many uncontrolled possible data sources/sinks attached for such a device to be able to handle. Now, that said, even a dumb terminal can be considered an embedded device - but that device is designed to allow someone ELSE to interpret the commands, and the commands the embedded device then interprets is very limited (usually just the handling of escape sequences, with some escape sequences generated based on the keyboard). As a terminal, it doesn't care what the characters coming in are. Which is why some things go bad when a binary file gets sent to the terminal - a lot of characters just can't be interpreted, and if one of those changes the terminals keyboard/display handling (arbitrary font changes for instance), the result is usually difficult to recover. Sometimes you even have to turn the terminal off and back on to recover (ie, a hard reset).

The usual communication path is more like:

person -> keyboard/display -> serial line (used for a console) -> computer -> serial line -> embedded device

This way, arbitrary data not significant as far as the embedded device goes, is completely separated. Error messages/commands/data input that the person does is first interpreted by the computer. Data that involves the embedded device is then sent along a dedicated serial line without all the other stuff.

There is still a significant amount of error handling required by the embedded device. It must accept valid commands and data (may require a specific protocol structure), reject improper commands and data (so it can recover) and provide appropriate responses to its input (which may also require a specific protocol structure).
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Serial communication problem RS-232 - USB(FTDI-chip) fenomax Programming 3 11-26-2011 06:57 PM
Experience with 8 bit serial AND parity with HL-420 USB-RS-232 converter? cordata Linux - Hardware 4 06-22-2009 09:47 AM
Reading/Writing to serial ports (Rs-232). linux_chris Linux - Software 9 12-10-2008 02:05 PM
Serial Port (RS-232) programming on a Linux Machine tmclint Linux - Software 2 03-26-2008 09:36 PM
I want to sent string out to serial port com1 (RS-232) lek171 Programming 1 12-25-2005 04:44 PM


All times are GMT -5. The time now is 12:38 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration