I'm working on some application using Qt framework, it uses serial port and need to receive some data, problem is that data is organized with some protocol, which i parse in readyRead() signal handler(slot), at the same time, i need to wait for parsed message with some timeout. So, to wait, i use QThread::msleep() after sending, but i've noticed, that when thread goes to sleep in msleep(), readyRead will be emitted only after msleep() will be finished. My question is, why readyRead can't wake up thread? Qt signal is not working like real Unix signals?
If you have single thread application readyRead slot not executes immediatly you got data on port. Read about Qt::QueuedConnection in QObject::connect(). When readyRead signal emits in serial port class it just added to queue of events (in global event loop). All events will be executed later by QEventLoop (inside QApplication instance).
Looks like you sleep your main thread so QEventLoop cant execute anything while sleeping. In this case you need to read your port from another thread to avoid main thread sleeping.
Related
How is parallel processing achieved in Qt. Suppose i need to call two functions which performs serial communication with multiple serial devices connected.
Func_A() handles serial communication with Device 1 and Func_B() handles serial communication with Device 2 and so on, but both needs to be communicated in parallel and not sequential .
The motive is to communicate with multiple devices connected through serial/Ethernet at the same time.
If you use non-blocking functions for communication, you can handle all your serial communication within the same thread with no issue.
Each device (QSerialPort) will emit a signal (i.e. call a function) when data is received. From there you can decode this data in the corresponding slots. Sending data can be triggered either by UI events, by timers, and by any other event.
This is the simplest.
If you really do heavy computations when encoding/decoding communication, you can create several QThread, one to handle each device. And then, you can connect signals between your different threads with Qt::QueuedConnection (automatic) to avoid the need for mutex or other inter-thread synchronization logic.
So I have a device set as the I2C master, and the rest of the devices on the bus are set as slaves. The master sends a command to each slave, and the slave executes this task (running motors, etc, important time-sensitive code). I would like to be able to know when the slave is finished executing its task. The only way I can see to do this is to constantly have the master poll the slave, but this creates an issue, because every time the master polls the slave, it triggers and i2c interrupt on the slave and quits running the motor code for a short amount of time.
Is there anyway to solve this? I was thinking of setting all devices as a master, so then when each device finishes it task, it can send the data over saying that it is done, without the need for polling. The issue with this is I'm worried about data collision over the bus with devices possibly trying to talk at the same time.
What is the correct way to solve this issue?
Let the slave disable its I2C interface while it's running a time-critical task, and re-enable afterwards. Then, the master can poll as often as it wants to, it would get no ACK from the busy slave, and the slave won't get any interrupts either.
The wikipedia entry states:
In computer system programming, an interrupt handler, also known as an interrupt service routine or ISR, is a callback function in microcontroller firmware, an operating system or a device driver, whose execution is triggered by the reception of an interrupt.
How is ISR a callback. Is it the PC value stored on stack itself is the callback function?
I.e., the ISR calls the interrupted function back. Hence the interrupted function is a callback.
A bit of setup code stores the address of the ISR function in the interrupt vector table to say "call me back at this address when the interrupt occurs".
To be clear, the ISR itself is the function that is "called back". The interrupted code is not the callback; it is merely "interrupted" and later "resumed".
ISR calls the interrupted function back
No, it doesn't, the program counter register is restored from stack like the return instruction does. ISR is a 'callback' because it is called via its address (stored in an interrupt vector table), and not directly.
Micro-controllers have an interrupt vector table in their flash memory at a known location. The table contains the addresses of all the ISR (reset interrupt, timer interrupts, GPIO interrupts, etc.). When an interrupt is enabled, on a specific trigger the ISR function is called: the application program is interrupted, the program counter and the processor registers are saved in the stack and the interrupt code is called. When the interrupt code is finished, the application is restored and the application program is resumed.
I am having a method and signal. From one process which is developed in Qt Creator 5.2.1, has 1 method and 1 signal.
The method is called using QDbusConnection and QDbusMessage.
The signal is connected with one slot.
A remote application which is to be developed in C should call the method remotely and should emit signal.
I need to know the sequence to remotely run the method and the sequence to emit signal.
Please help me the sequence in C program. No clear picture I found while surfing in internet.
I need to set an interruption for the serial (uart) port in Beaglebone, in such a way that when the serial port receives any info an interruption (function) is automatically activated doing something with the received data.
I have searched methods to do so, but no success. I have worked with interruption for uart ports in microcontrollers, and I though I could do the same in Beaglebone.
Any suggestion to do it?
Thanks in advance.
Use the
select() or poll()
system call to do a polling on the tty file. As soon as any data arrives on the device file, you take the data and do the stuff you intend to do.
Or you can run a dedicated thread which continuously polls the uart and deals with the data.