12-23-2024 09:52 AM - edited 12-23-2024 10:22 AM
Hello Reader,
I have a 3rd party FPGA board that is sending data over UART and I am reading the data using VISA VIs. As of now, I just have a simple test VI that seems to receive data without any issues at 2M Baud.
In the final application, FPGA is collecting packets of 25 bytes every 133.75 micro seconds. Total number of samples will be 25 Bytes x 4096 = 102,400 Bytes, so required data should be collected by FPGA every 0.54784 seconds.
As of now, there is no buffering on the FPGA side, FPGA is sending data out every 133.75 micro seconds over UART. Now, I know that PC cannot deterministically operate at this fast speed, but the option of 2M Baud with buffering gives me a hope that there is something working the background which can support this high speed transfer with a buffer on PC side, similar to DMA FIFOs.
EDIT: I am imagining that VISA will collect these 25 byte packets, buffer them (I should use 2x or 4x buffer of 102400 as buffer size) and then I will use "byte count" option and set it to 102400 to read them all at once in about every ~.6 seconds.
1) Is my understanding correct or close? I would really want to avoid buffering of 102400 bytes on FPGA side due to resource limitation, I do have double buffering of 25 bytes packets.
2) Can I rely on VISA's buffering and except a lossless communication?
3) Any cautions, warnings, suggestions or recommendations for my application?
Thanking you for your time.
X
Solved! Go to Solution.
12-24-2024 07:54 AM
I'm not sure if there is a limit to how large of a buffer VISA will allow you to have. That is something I would need to dig around to see if I can find anything on it. Personally, I would have a loop that did nothing but read from that port and send the data through a queue to a processing loop. The queue size, something that is a lot easier to understand, would then be your limiting factor. There should be no wait at all in that loop as it will be trying to keep up with the data stream.
12-24-2024 10:09 AM
Hello crossrulz,
Thank you so much for your reply.
As you pointed out about the buffer size, I did some looking around myself but did not find any clear information.
Source_LV_Forum_From_2002Says "Windows does not specify a maximum size but I've seen requests for buffers greater than 32KB fail." If I go by this, I should be fine with 1x or even 2x buffer. That would at least keep reading data loop time around ~.6 seconds. I will also experiment and share my findings here once I am at that point.
I will take your suggestions for designated read loop and queuing implementation.
Any other word of caution?
12-24-2024 10:53 AM
The only thing I can think of is to make sure your baud rates match. That's the main thing. Everything else is taken care of under the hood. Setting it up as crossrulz suggests should make things quite easy - provided you set it up properly, which I think crossrulz, you have something to say about that, right? Or something to show?
12-24-2024 11:00 AM
Hello billko,
Thank you for the reply. Okay, understood, I will make sure that the buad matches. Good thing is, I control baud on both the sides (maybe it is a scary thing haha).
I will wait to see if crossrulz has anything to add.
Best
X
12-26-2024 08:56 PM
@billko wrote:
...which I think crossrulz, you have something to say about that, right? Or something to show?
What are you trying to imply? You think I might have a video on proper serial communications or something?
The main thing for the OP to worry about is the messaging protocol being used. It sounds like a streaming protocol, most likely binary due to the heavy amount of data being passed. So the OP needs to make sure there is a clear synchronization before the stream starts or have framing messages to ensure data is being interpreted correctly.
12-31-2024 02:49 PM - edited 12-31-2024 02:51 PM
I did it!! ヾ(⌐■_■)/
Thank you crossrulz and billko.
I am reading 26*4096 (106,496) bytes every ~ second. VISA node supported a buffer size of 4x 106,496 (425984) Bytes. Implemented a state machine. Everything is working just as needed.