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.
Related
I am a high school student, who is not very familiar with FPGAs and the Xilinx line.
I am running a ring oscillator module on a Zybo Z7 board. I am also running a counter module, which I want to sample at a high rate. I am currently sending the data through AXI to the ZYNQ processing system, and then using the inbuilt UART to USB buffer to send the data through a USB cable to my computer. On the computer side, I treat this input as a virtual serial line, and use a python script to take and log the data from an IOstream. This method takes very long, however, and I am trying to increase the sample speed. Thus, I was wondering if I could bypass the onboard PS, and connect the FPGA fabric directly to the UART buffer.
I have tried optimizing my PS code, which I have written in C. I have reached the point where it takes 30 oscillations of the onboard ZYNQ clock between samples. Now, however, I have created a newer and more reliable sampling framework in the FPGA logic, which requires a 'handshake' mechanism to start and stop the counter between samples. It takes a very long time for the PS to sample the counter, send the sample, and then restart the counter. Thus, the uptime of my sampling framework is a fraction of what I want it to be. Removing the PS would be ideal, as I know I can automate this handshake signal within the PL if I am able to connect it to a UART interface.
You can implement logic in the PL that can handle the UART communication thus bypassing the PS.
Here's an implementation you can try using:https://github.com/jakubcabal/uart-for-fpga
You would connect the UART pins to one of the Zybo Z7 Pmod ports and use an external USB to UART adapter such as this one, anyone would work as long it supports 3.3V: https://www.adafruit.com/product/5335
The adapter built into the board is connected to directly to the PS MIO pins and cannot be used by the PL.
I am new in OpenCl. I was wondering if you could answer my following question.
I have a queue of data packets which acts like router queues. The packets arrive, store in the queue, then processed by the router. Finally, they are inserted to the out-going queue.
I am trying to use OpenCl to process the packets concurrently. I know that we can use the buffers, for example, to transfer data between the host and OpenCl devices. We load the buffers with input/output data. Then, we set the kernel parameters using these input/output buffers. when the kernels running are done, we read the data from the OpenCl devices.
My question is that, how can I write/read a buffer for each single data packet independently of the other packets?
In other words, suppose one data packet arrives, the router needs to process it on a computing device (e.g. core #1 on GPU). Then another packets arrives. The router needs to process the second packet on a different computing device (e.g. core #2 on GPU). The processing of these two packets are actually happening concurrently but asynchronously. How this could be implemented in OpenCl?
Thanks for your reply in advance.
Regards,
Alireza.
I'd recommend a ring buffer of OpenCL buffers to hold your incoming data, and as you fill them enqueue kernels to work on them. You're only going to get good performance if the kernels have parallel data to work on. Even GPUs that can work on multiple kernels at the same time that number is small (like perhaps 2). The real power is the parallel computation within a kernel, otherwise your hardware will be idle.
To get kernels to run in parallel you need to use separate command queues since using a single command queue implies serial execution (unless it is an out-of-order command queue, but those are not widely supported).
I'm building an electronic device that has to be prepared for RS232 connections, and I'd like to know if it's really necessary to make room for more than 3 pins (Tx, Rx, GND) on each port.
If I don't use the rest of signals (those made for handshaking): am I going to find problems communicating with any device?
Generally, yes, that's a problem. The kind of problem that you can only avoid if you can give specific instructions to the client on how to configure the port on his end. Which is never not a problem, if that's not done properly then data transfer just won't occur and finding out why can be very awkward. You are almost guaranteed to get a support call.
A lot of standard programs pay attention to your DTR signal, DSR on their end. Data Terminal Ready indicates that your device is powered up and whatever the client receives is not produced by electrical noise. Without DSR they'll just ignore what you send. Very simple to implement, just tie it to your power supply.
Pretty common is flow control through the RTS/CTS signals. If enabled in the client program, it won't send you anything until you turn on the Request To Send signal. Again very simple to implement if you don't need flow control, just tie it logically high like DTR so the client program's configuration doesn't matter.
DCD and Ring are modem signals, pretty unlikely to matter to a generic device. Tie them logically low.
Very simple to implement, avoids lots of mishaps and support calls, do wire them.
And do consider whether you can actually live without flow control. It is very rarely a problem on the client end, modern machines can very easily keep up with the kind of data rates that are common on serial ports. That is not necessarily the case on your end, the usual limitation is the amount of RAM you can reserve for the receive buffer and the speed of the embedded processor. A modern machine can firehose you with data pretty easily. If your uart FIFO or receive interrupt handler or data processing code cannot keep up then the inevitable data loss is very hard to deal with. Not an issue if you use RTS/CTS or Xon/Xoff handshaking or if you use a master/slave protocol or are comfortable with a low enough baudrate.
I am working on a project which requires data to be sent FROM PC TO FPGA,which processes the data and sends it BACK TO PC.
The board I am using is Atlys™ Spartan-6 FPGA Development Board.
The data is to be sent as 1 byte , because 1 byte is processed at each rising edge of the clock.
Could you please suggest me ways of sending data to FPGA ?
Thanks
Pick some method of communication that you have access to IP (intellectual property) cores for. For example, if you can readily access a UDP/IP core for your FPGA, then use that. If you have to develop the HDL yourself, serial protocols (UART, I2C, etc) will be simpler blocks to write. In general, HDL takes longer to develop, debug, and test.
UDP has some advantage because you can use tools like Wireshark to capture packets on the PC (once you get past the initial hurdle of actually getting packets to/from the FPGA). Plus, many people are familiar with UDP in various programming languages (C, C++).
In any case, you'll probably spend time with an oscilloscope and logic analyzer checking out signal levels and timing when data is sent to/from the FPGA.
In my program the receiver has a bigger workload, should i make the sender wait for the receiver through methods like application level ACK?
You shouldn't directly send TCP ACK messages--those are handled at a low level by the OS. I'd look at the following in order of likelihood:
Is there some easy optimization on the receiver? It's pretty rare that you can really fill a network pipe more quickly than the receiver can handle the data. Make sure that the receiver has at least two threads: a network i/o thread and a work thread.
If the receiver is starting to panic, it could send a throttle message to the server, which makes the server cool its heels until the receiver catches up. This is more efficient than waiting for an ack message after every message, but it requires that the receiver know when it's about to fall behind, which might be difficult.
Alternately, the slowest but most reliable thing is to have the receiver acknowledge every message from the server, sort of like you mentioned. This wouldn't be a TCP ACK, but a special message in the data format that your sender/receiver are using for comm.