Redundant UART communication between FPGA and LabVIEW

[mishu]

Hi,

I have designed an UART core without any flow control for use with FPGA devices when communicating with LabVIEW. I am  looking for a way to receive (from FPGA to LabVIEW) data fast and correctly, hence I am investigating the following configurations for setting the VISA READ when to start or stop reading UART bytes:

1-with termination char: this is very tricky in the binary world as are the FPGAs, because it can trigger false stops sooner than expected. A solution will be to use a custom 3 termination chars like "/n/n/n" and LabVIEW will read till will receive this sequence. 

2- by counting the received bytes and compare them with the expected number of bytes and the process the data.

3- using flow control.

 

Which approach is better to be used? Or do you have another ideas?

Thanks,

V.M.

[jpeyron]

Hi @mishu,

I think one big determining factor to which way to handle the uart communication would depend on a couple of question.

First, will this uart process be used in an external project?

Second, are you only planning on using this uart process once or will it need to be more modular and will be used in different projects?

thank you,

Jon

 

 

 

  

 

 

[mishu]

Hi @jpeyron,

Sorry, but I dont understand what do you mean by external project. Regarding the second question, yes, the uart process both FPGA I am planning to be modular and user configurable depending on each application.

Thanks,

V.M.

[jpeyron]

Hi @mishu,

I'm sorry for any confusion.

1) My question was meant to see if you are you going to use this UART process for you and or your co-workers/classmates or are you going to be using the uart process on a project that will be sold and or used by many people not directly connected to you?

If you are trying to make this uart process more modular I would probably try to make a uart controller with flow control.

thank you,

Jon

[mishu]

Hi @jpeyron ,

Right now is just a part of my PhD thesis.  

Indeed the flow control configuration seems robust to be used.

 

Thanks,

V.M.