I want to use tcdrain with termios2.
The problem is the method is defined in termios.h, but not in asm/termbits.h.
It is not possible to use termios.h with asm/termbits.h together as there would have compilation errors as some of the structs are defined in both files.
Background: I would like to control my serial transmission by invoking tcdrain after write to make sure my data have transmitted before continue execution of my program. I would like also use custom serial speeds (thus, using termios2).
How do I use tcdrain with termios2?
tcdrain is a simple ioctl call:
ioctl (fd, TCSBRK, 1)
Related
Reading Qt signal & slots documentation, it seems that the only reason for a new style connection to fail is:
"If there is already a duplicate (exact same signal to the exact same slot on the same objects), the connection will fail and connect will return false"
Which means that connection was already successful the first time and does not allow multi-connections when using Qt::UniqueConnection.
Does this means that Qt-5 style connection will always success? Are there any other reasons for failure?
The new-style connect can still fail at runtime for a variety of reasons:
Either sender or receiver is a null pointer. Obviously this requires a check that can only happen at runtime.
The PMF you specified for a signal is not actually a signal. Lacking proper C++ reflection capabilities, all you can do at compile time is checking that the signal is a non-static member function of the sender's class.
However, that's not enough to make it a signal: it also needs to be in a signals: section in your class definition. When moc sees your class definition, it will generate some metadata containing the information that that function is indeed a signal. So, at runtime, the pointer passed to connect is looked up in a table, and connect itself will fail if the pointer is not found (because you did not pass a signal).
The check on the previous point actually requires a comparison between pointers to member functions. It's a particularly tricky one, because it will typically involve different TUs:
one is the TU containing moc-generated data (typically a moc_class.cpp file). In this TU there's the aforementioned table containing, amongst other things, pointers to the signals (which are just ordinary member functions).
is the TU where you actually invoke connect(sender, &Sender::signal, ...), which generates the pointer that gets looked up in the table.
Now, the two TUs may be in the same application, or perhaps one is in a library and the other in your application, or maybe in two libraries, etc; your platform's ABI starts to get into play.
In theory, the pointers stored when doing 1. are identical to the pointers generated when doing 2.; in practice, we've found cases where this does not happen (cf. this bug report that I reported some time ago, where older versions of GNU ld on ARM generated code that failed the comparison).
For Qt this meant disabling certain optimizations and/or passing some extra flags to the places where we know this to happen and break user software. For instance, as of Qt 5.9, there is no support for -Bsymbolic* flags on GCC on anything but x86 and x86-64.
Of course, this does not mean we've found and fixed all the possible places. New compilers and more aggressive optimizations might trigger this bug again in the future, making connect return false, even when everything is supposed to work.
Yes it can fail if either sender or receiver are not valid objects (nullptr for example)
Example
QObject* obj1 = new QObject();
QObject* obj2 = new QObject();
// Will succeed
connect(obj1, &QObject::destroyed, obj2, &QObject::deleteLater);
delete obj1;
obj1 = nullptr;
// Will fail even if it compiles
connect(obj1, &QObject::destroyed, obj2, &QObject::deleteLater);
Do not try to register pointer type. I've used the macro
#define QT_REG_TYPE(T) qRegisterMetaType<T>(#T)
with pointer type CMyWidget*, that was the problem. Using the type directly worked.
No it's not always successful. The docs give an example here where connect would return false because the signal should not contain variable names.
// WRONG
QObject::connect(scrollBar, SIGNAL(valueChanged(int value)),
label, SLOT(setNum(int value)));
How I can write data in serial port, with delay between send's messages?
This is my code:
void MainWindow::on_pushButton_Done_clicked()
{
if(sport->isOpen()){
sport->clear();
QString cmd = Phase+Mode;
//Write Stop
sport->write("stop!", 5);
//Write Mode
sport->write(cmd.toStdString().c_str(), cmd.toStdString().length());
//Write Speed
sport->write(Speed.toStdString().c_str(), Speed.toStdString().length());
//Write Direction
sport->write(Direction.toStdString().c_str(), Direction.toStdString().length());
//Run
sport->write("start!", 6);
}
}
My device receives an error message when I call this function.
Thank you.
2 options:
use waitForBytesWritten to ensure the bytes are written and then a short sleep
however this will block the thread and will block the gui
the other is using a QTimer to trigger another slot a few times and a field that will indicate what needs to be sent
Looks like you are trying to program some step motor controller or something similar.
Usually in such controllers you should wait for controller response to verify that command was processed properly.
It looks like that your design of code is very bad. Move everything related with this controller to separate class, which has set of slots, something like: starRotateLeftWithSpeed(double). Code will be cleaner and it will be easy to use thread if you decide to use methods like waitForBytesWritten proposed in another answer.
Definitely you should read controller manual more carefully.
I need to read a message incoming every 500ms from the serial COMx or /dev/ttySx interfaces under jruby.
What I am trying to do is to translate this example to Ruby in order to retrigger the listener.
I am learning jRuby so I started to activate the serial port and then I am trying to add the listener in this way:
java_import('gnu.io.RXTXPort') { 'JSerialPort' }
begin
sp=JSerialPort.new('COM6')
sp.setSerialPortParams(38400,8,1,0)
rescue
puts #error_message="myerror #{$!}"
ensure
sp.close
end
It seems to work.
Next is to add the listener which in the above example is described at this line
serialPort.addEventListener(new SerialReader(in));
This is described here where an addListener method is described.
I tried many ways to call the addListener methods, but I don't manage to call by jRuby such an inner method.
I tried sp::RXTXPort::addEventListener with no luck. Long research googling set me to stall (and some frustration).
Any help welcome.
In my user space Linux application, I have a thread which communicated to the main process through a pipe. Below is the code
static void _notify_main(int cond)
{
int r;
int tmp = cond;
r = write( _nfy_fd, &tmp, sizeof(tmp) );
ERROR( "write failed: %d. %s\n", r, strerror(r) );
}
Pretty straight forward. It's been working fine for quite a while now. But recently, the write call will fail with "interrupted system call" error after the programme went under some stress test.
Strangely, the stuff actually went through the pipe no problem. Of course I'd still like to go to the bottom of the error message and get rid of it.
Thanks,
The write(2) man page mentions:
Conforming to
SVr4, 4.3BSD, POSIX.1-2001.
Under SVr4 a write may be interrupted and return EINTR at any point, not just before any data is written.
I guess you were just lucky that it didn't occur so far.
If you google just for the "interrupted system call", you will find this thread which tells you to use siginterrupt() to auto-restart the write call.
From http://www.gnu.org/
A signal can arrive and be handled while an I/O primitive such as open
or read is waiting for an I/O device. If the signal handler returns,
the system faces the question: what should happen next?
POSIX specifies one approach: make the primitive fail right away. The
error code for this kind of failure is EINTR. This is flexible, but
usually inconvenient. Typically, POSIX applications that use signal
handlers must check for EINTR after each library function that can
return it, in order to try the call again. Often programmers forget to
check, which is a common source of error.
So you can handle the EINTR error, there is another choice by the way, You can use sigaction to establish a signal handler specifying how that handler should behave. Using the SA_RESTART flag, return from that handler will resume a primitive; otherwise, return from that handler will cause EINTR.
see interrupted primitives
I am using fork() and execvp() to spawn a process that must believe it is connected to an interactive terminal for it to function properly.
Once spawned, I want to capture all the output from the process, as well as be able to send input to the process.
I suspect psuedo-ttys may help here. Does anyone have a snippet on how to do this?
You want to call forkpty(). From the man page:
#include <pty.h> /* for openpty and forkpty */
pid_t forkpty(int *amaster, char *name, struct termios *termp, struct
winsize *winp);
Link with -lutil.
The forkpty() function combines openpty(), fork(), and login_tty() to
create a new process operating in a pseudo-terminal. The file descripâ
tor of the master side of the pseudo-terminal is returned in amaster,
and the filename of the slave in name if it is not NULL. The termp and
winp parameters, if not NULL, will determine the terminal attributes
and window size of the slave side of the pseudo-terminal.
Your parent process talks to the child by reading and writing from the file descriptor that forkpty stores in "amaster" - this is called the master pseudo-terminal device. The child just talks to stdin and stdout, which are connected to the slave pseudo-terminal device.
Expect was already mentioned for use via Tcl, but it can also be used without Tcl by treating it as a C library and calling the API documented here
There's a package called "expect" which you should use. It uses a scripting language called tcl (pronounced tickle).
https://core.tcl-lang.org/expect/