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

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?

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()?

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.

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).