07-17-2019 08:53 AM
@colorizedice wrote:
Maybe I didn't make my point clear. I use the pc to send a trigger signal to rpi, and when rpi received the trigger signal, it will connect to the fpga and get data from it, then, rpi will send the data back to pc.
Maybe your description is too simplistic, but what do you even need the RaspberryPi for? Why not connect the PC directly to the FPGA?
07-17-2019 09:06 AM
The reason is we need to move the fpga around, and with the rpi, we can have more flexibility. For example, in some cases, we just use the rpi to collect data, rather than send the data to pc part.
07-17-2019 10:06 AM
Hi, GerdW:
I found several interesting things.
1. when I just send "yes" trigger signal (UDP) from PC to Rpi, it works well. It can trigger the python code in RPi and RPi will then communicate with FPGA and get a result.
2. If I let the RPi send back the generated result to PC (by UDP), the vi in PC part will be stuck at the "udp read" part. However, if I set the wait time in the while loop as 6000 ms, the UDP vi in PC part will receive the result successfully. But you know, 6 seconds is to slow for my testing, this solution is not actually working for me.
3. I wrote a new python code in RPi side. It will send back a random number once it received the trigger signal "yes". This sample code works well with same Labview vi in PC part.
So, I'm just thinking when the RPi has a tcp connection with FPGA, it will slow down the speed of UDP communication with PC side...
07-17-2019 10:08 AM
UDP is a bad choice in this instance, made even worse since it sounds like you are using sockets to handle the communication.
I would suggest you use the Twisted package on the RPi instead. There are some excellent tutorials to get you started and once you figure it out you have a robust, scalable system and handling two or ten TCP connections will be no problem.