Implementing tight time constraints for read/write with USB serial (ftdi_sio)

Thomas Bracht Laumann Jespersen laumann.thomas at gmail.com
Mon Sep 3 15:12:35 EDT 2018


Hello all!

I'm working on a project where we want to integrate into a production line and
listen on connected devices, and the challenge is that our setup needs to be
fast enough.

Let me try to explain the setup.

There are some 80+ devices on the network. They are connected in a multidrop
talking PROFIBUS at a speed of 1.5MB.

I have an RS485<->USB serial cable that uses the ftdi_sio driver to listen on
the network. It is identified as a FT232RL.

Just listening and de-constructing the PROFIBUS communication blocks that are
coming through is not a problem. The problem is when I need to reply to messages
in the network.

At first I was seeing reads from the serial port taking either ~.002ms or ~16ms,
which I assume is due to buffering on the chip. I then learned about setserial
and tried adjusting the latency to 1ms. This gives me read times at around ~4ms
on average (but sometimes going above 10ms). I'm looking for ways to
disable/minimize the buffering on the FTDI chip, but I also suspect that the
ftdi_sio driver does some buffering.

The challenge is that my application needs to act within 100 tbits, ie in around
~.066ms. That is the window in which I need to begin transmitting a reply. Is
there a way to achieve this with the ftdi_sio driver or do I need dedicated
hardware for this?

I guess my question is: Is it possible to achieve sub-millisecond response times
in a "standard" Linux (ie a desktop variant)? Or is it necessary to look into
real-time Linux or other specific kernel configuration?

As an aside, I'll mention that I've looked into libftdi as an alternative (could
it be?), but since it specifically unloads the kernel driver I'm not sure I
should be asking about that here :-)

To be honest, I'm not sure if kernelnewbies is the right place to ask, if not,
I'll be happy to take my questions elsewhere :-)


All the best,
-- Thomas



More information about the Kernelnewbies mailing list