We now run the program and encounter the following error message
The “Standard Input is not a Terminal Device” error message occurred while running the program from the keyboard.
However, when we run the program via SSH remote login, this error does not occur.
Could you please help us analyze the cause of this mistake?
You will need to provide a lot more details on what is being run, and how. However, as a general thought (not suitable for a conclusion), standard input implies a serial character device, perhaps with some terminal control commands being available to “standardize” control. A UART obviously fulfills the serial character part, but only with the right driver (pure serial character devices might not be properly controllable or in some way “standardized” in how it is used). SSH, when it logs in to a remote system, is very similar, but guarantees that it is set up as a terminal.
Note that when people use a serial UART for data, it simply has settings for speed, parity, and stop bits. If you look at any of “/dev/ttyTHS#” or “/dev/ttyS#” (such as “ls -l /dev/ttyS* /dev/ttyTHS*”) you’ll see group ownership.
Note that the device special files in “/dev” are the result of a driver. In the case of a particular # matching both a “/dev/ttyS#" and a "/dev/ttyTHS#” you are looking at the same UART, but different drivers. You would not want to use the same UART simultaneously with two different drivers, and thus for example you would not use both ttyTHS1 and ttyS1 at the same time (it usually does not work out well to use two drivers on the same hardware at the same time).
The reason I’m pointing this out is that if you look at the “group” from “ls -l /dev/ttyS* /dev/ttyTHS*” most of them will be group “dialout”. This is a general UART without terminal code running on top of it for human interface devices (a keyboard). The ones which are group “tty” are in fact running code needed for a keyboard. In this case it is the software “nvgetty” running on that device, and the keyboard would be talking to nvgetty, and in turn it would be nvgetty which talks to the UART (or simulated UART).
Having a lot more information about which hardware you are using, and which possible device special file is used, and who the group is for that file, might help. SSH takes care of all of that automatically, and it sounds like you might need to assign a getty (such as nvgetty) to talk to the UART.