I am trying to run an ncurses GUI application on an ARM board. I am running it using the serial console ttyAMA0 port. But when I run the ncurses program, the other processes running in the background will print debug messages i.e qDebub, qWarning into STDOUT i.e on the GUI layout and hence results in noise. I think the problem is because all the processes are using the same console device.
So is there is a command line or programmatic solution for this problem so that I could not see the other process' STDOUT on my ncurses GUI ?
P.S: I have tried GNU screen and gdb solution and they work fine. But I want alternative solution for this
Related
I'm currently displaying serial output from my embedded device in a Mac OS terminal using the command
screen /dev/tty.SLAB_USBtoUART 115200
Instead of displaying the output in the terminal, I'd like to be able to read it line by line in my C++ (qt) app so I can process it and display it in a GUI.
I tried to create a QProcess object to run the screen command above, but screen fails, saying "Must be connected to a terminal".
Is there a way I can "fake" the connectedness to a terminal so that the QProcess will be able to successfully run the screen command? I don't need to input any commands, I just need to capture the output that the embedded device is writing.
You can use boost serial port to read the incoming data. Be aware that this will have to be done in a thread or using Qt Concurrent. From this thread you can send signals that connected to the correct slots of your data display will take the data and display it. However, Qt also provides a serial port class that you can use: QSerialPort. I would recomend using QTextEdit as your display widget and QTextEdit::append for your slot.
I can print debug messages to GDB console with printf or cout, but none of the data actually shows up on the HDMI display running on /dev/fb0
Is there a way to print data directly out on the display without having to write to /dev/fb0
This is Raspberry Pi 3, running Raspbian Lite OS
The program is supposed to run in the background from /etc/rc.local
From your comment it seems that you are running the HDMI in a text mode a framebuffer console on the HDMI (rather than something like X) and want to print messages to it.
For that purpose in most configurations, you can write to /dev/console
Code doing this would need to run as root (as something launched from rc.local would) or the permission of the device node would need to be changed.
You can also typically (as the owner or as root) write to the pty devices for GUI-mode terminals, ssh sessions, etc.
Finally note that there is the unix-style write command which would write to a user's terminal session(s).
I'm doing some embedded C++ development and I have a call stack being printed from my device to a Mac terminal via a UART.
I'd like to create a C++ app that somehow listens to the terminal output, detects a callstack, and automatically converts the addresses into symbols.
I can do the conversion, but I'm not sure if there's a way for my app to be notified when the terminal output has changed, or even to periodically poll the open terminals and extract their contents?
I am finding a Ubuntu OS command, which lets the program to read the data from keyboard even if the program is in background. I tried to search it a lot but got no success. If any Ubuntu/Linux programmer knows the OS command which lets the program to do so, Please share it with me.
I am a beginner of Ubuntu programming.
You can use the Linux input subsystem to read events from mice and keyboards. It will only work if your application has the necessary privileges. Basically, you have to run the application as root for this to work.
If you cannot run as root, you should not be attempting to monitor the keyboard anyway.
You can create an X11 application to monitor keyboard events in the current session. It only works for the current user, and in the current graphical environment, and may not be able to observe privileged dialogs, for example password inputs. For details, look at the application shortcut launcher for your desktop environment; all Linux DEs I've ever heard of have one.
I think the old Linux Journal articles, The Linux USB Input Subsystem and Using the Input Subsystem, are still one of the best introductions to the Linux input subsystem. Most Linux distributions nowadays also support uinput, a similar device that allows injecting input events back to the kernel subsystem, designed to allow user-space input device drivers. Their interfaces are described in /usr/include/linux/input.h and /usr/include/linux/uinput.h. I recommend you start at the above articles, and then look at some input and uinput examples.
If you are comfortable using a program, have a look at Logkeys project
. It directly takes input from /dev/input/event*.
How do I exactly make a C++ program interact with another program and interact with something I have clicked on.
Example: If I wanted to make an MSN auto reply program and I would have a dialog box that would ask me what I would want to type and than the program would paste that into the MSN chat box.
It turns out that X by itself doesn't let you do this, but you can make it possible by installing the Xtest extensions (and then reading about them...)
Other approaches would be to inject events at the operating system keyboard/mouse level or using some existing or patched in interface of the target program. A lot of unix-ish tools can be set up to accept command input on stdin or accomplish a lot via command line options for scripting purposes.