Fast data processing from serial port

[crossrulz]

---

@GerdW wrote:

What's the receiver at the other end (probably your PC)? Can it handle this baudrate?

---

The FT232H is a USB-UART chip.  So the OP must have a USB cable going to the PC.  It should show up as a COM port, assuming the right drivers are installed.

My next question would be can Windows handle a COM port with that kind of baud rate?  If not, you will probably have to go with the FTDI Direct Drivers, which would be direct DLL calls.

[teslista]

FTDI drivers are very good and proven, thats why I used FTDI IC instead of MCU's USB VCP. It works good even with "standard" FTDI VCP drivers (there was just some troubles when I wasn't using timed loop, but while loop instead) - because windows are not realtime OS and while loop was too slow, causing driver buffer overflow... Timed loop, of course, can work properly only with dedicated procesor (with multicore processor), setting priority of loop to maximum...

And yes, receiver is my notebook (with dual core i7)

FT232H supports 40M byte/s ~ 320Mbaud/s (with synchronous parallel interface)... so direct drivers are probably meant for that speeds...

[vlad.mihai]

Hi there,

I have the same problem. I am designing a custom DAQ which is based on an FPGA.

The data is :16 channels of 16-bit ADC data  along with an 8-bit termination char which  is sent each 10 ms via UART at 115200 baud rate.  (264 bits in total, 256 data+8 char termination)

In LabVIEW I designed an event based state machine which is placed on a producer consumer structure. The main loop the producer reads continuously data (the corresponding state) from VISA and send it to the consumer. I have measured the execution time of the state which handles this operation and: without any delay in it (delay ms=> 0) it takes somewhere around 15 ms to execute,(note that this value is not stable, it changes a lot from 0 to 15), but if I put a small delay, lets say 18 ms, the execution loop is about 19-20 ms, so, this means that the execution is about 1-2 ms?

If not, can you give me some tips to handle correctly this readout at 100 samples per sec?

UART is set with the termination char enabled.

Thanks,

Vlad

[GerdW]

Hi vlad,

remove the event structure and the wait inside the case.

Let VISARead handle the timing - it will wait for the TermChar in your message…

[Ben]

---

@vlad.mihai wrote:

Hi there,

I have the same problem. I am designing a custom DAQ which is based on an FPGA.

The data is :16 channels of 16-bit ADC data  along with an 8-bit termination char which  is sent each 10 ms via UART at 115200 baud rate.  (264 bits in total, 256 data+8 char termination)

In LabVIEW I designed an event based state machine which is placed on a producer consumer structure. The main loop the producer reads continuously data (the corresponding state) from VISA and send it to the consumer. I have measured the execution time of the state which handles this operation and: without any delay in it (delay ms=> 0) it takes somewhere around 15 ms to execute,(note that this value is not stable, it changes a lot from 0 to 15), but if I put a small delay, lets say 18 ms, the execution loop is about 19-20 ms, so, this means that the execution is about 1-2 ms?

If not, can you give me some tips to handle correctly this readout at 100 samples per sec?

UART is set with the termination char enabled.

Thanks,

Vlad

---

You "TImeout" event case where you have your state machine is using a "1 ms" timeout setting. The Time Out event will not fire unless all other events do not fire AND 1 ms has passed.

So your code is most likely running faster.

Ben

Spoiler

I have done multiple projects with serial above 1MBaud. Both time required special adapters.

But for a real challenge, try to demux a two channel digital microphone from a single DI line using another DI line as the clock. I was only able to sample the line a 400MHz. I simply could not write code fast enough to keep up with the 800MHz sample rate. And no, no FPGA used. Only a PXI running Windows. I would love to share that code with the community just to see if anyone could get it running a 800MHz.

[vlad.mihai]

Hi Ben,

Thanks for your reply.

Yes I know about the timeout setting, I have put it 1 ms because I do not want to be 0, and remove the wait (which was used only for debugging purposes). But now is 0 ms, and I am missing something else here? or this should be enough?

I hope it will be stable like this. If not, I will  implement the solution proposed by GerdW.

Thank you,

Vlad

[vlad.mihai]

Hi guys,

The problem was not really solved, hence now I have observed another issue.

If I set Visa to read only 8 bytes, the execution time of my state is about 1 ms, but if I set it back to 32 then the execution time is roughly 16 ms, but varies all the time.

Can anyone explain this?

PS: these are reading without any char termination

Vlad

[Ben]

I suggest you listen to Gerd.

Toss the event structure (well technically, spate your serial code from the event structure) and switch over to using the termination character to mark the end of a message from your widget. If you write the code correctly the processing will be able to keep up with whatever your widget can send.

Ben

[vlad.mihai]

Hi,

Yes, I had corrected a little bit my code and works well, but I just figure out, that is a chance that my data will be as the same value as termination char, hence I could get the reading to stop earlier. From FPGA I am sending binary data.

I will dig in to that, but maybe I will drop off the termination char thing, and use the byte counting thing.

Vlad

[Ben]

---

@vlad.mihai wrote:

Hi,

Yes, I had corrected a little bit my code and works well, but I just figure out, that is a chance that my data will be as the same value as termination char, hence I could get the reading to stop earlier. From FPGA I am sending binary data.

I will dig in to that, but maybe I will drop off the termination char thing, and use the byte counting thing.

Vlad

---

That is one of the situations where the term character will not work. The interfaces for many widgets avoid the raw binary data transfers due to that issue. Very old gizmos that wanted to mac out comm speed would use escape characters like SOT and EOT and/or "bit stuffing" (where the termination character is trapped and replaced with something else).

But if you can rely on the packets size being fixed AND have a method to ensure the packet is properly framed (as in you are not reading the last part of the first message and the first part of the next message) then go with the fixed read size.

Ben