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

[Thomas Bracht Laumann Jespersen]

Hi Valdis,

Thanks for your reply!

Failure in our context means that we cannot participate as an alternative master
in the PROFIBUS network.

I'll try to explain briefly what the intended setup is: A PROFIBUS network
consists of exactly one master (a class 1 master, or MC1), and a number of
slaves. All the slaves are silent until queried for information. The MC1 goes
round-robin asking each slave for periodic status updates, to keep tabs on how
things are going. PROFIBUS is _very_ deterministic: only station may be
communicating at a time and the master orchestrates the exchange of information
[0].

Our challenge is that we want to pull run-time data out of this network, and
re-programming MC1 to extract more data is not an option. So failure also means
we cannot monitor the system as well as we want.

Fortunately, PROFIBUS also specifies a class 2 master (MC2) that is intended for
maintenance purposes [1]. The MC2 design allows other stations to dynamically
enter and leave the network. The idea is to use the gap time to act as a master.

To orchestrate this, the masters pass a token around. Specifically, the MC1
periodically tries all possible network addresses to see if any other stations
want to accept the token. If so, then the station must respond with a specific
"accept token" message. Once the MC1 station sees the accept, it passes the
token to the new MC2 and the two masters then pass the token back and forth.

An MC2 station leaves the network by simply failing to return the token three
times.

We have a test setup where I have been able to successfully send the "accept
token" message, but by the time the MC1 station passes the token (and my program
sees it), it has already failed to pass it back.

The problem is that response transmission has to begin within 100 tbits of
response receipt (this is called the slot time). That is, from the time I see a
message I should respond to, I must begin transmitting a response within 100
tbits. In our test setup we run 115 kBaud, so our slot time works out to about
0.868ms. In the production setup, we need to go even faster, at 1.5Mbaud, so the
slot time dips to ~0.066ms.

[0] https://www.felser.ch/profibus-manual/stationen.html
[1] https://www.felser.ch/profibus-manual/prinzip_des_token-passing.html


-- Thomas
On Tue, 4 Sep 2018 at 03:23, <valdis.kletnieks at vt.edu> wrote:
>
> On Mon, 03 Sep 2018 21:12:35 +0200, Thomas Bracht Laumann Jespersen said:
>
> > 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?
>
> (Hopefully you've already done all of the below - it's mostly for the
> others out there thinking about doing real-time work...)
>
> Step 0 is quantifying what a failure means.  Do you just miss a data point for
> a graph, or does something on the assembly line explode or equally bad, or
> something in between?
>
> Step 1 is firming up exactly what that 0.66ms is.  Does it start at the
> beginning of receiving the packet you care about, or when the last byte has
> arrived?  And are you counting until the first byte of the response leaves, or
> the last byte? Or are you counting until it's actually received at the target?
> (Note that some statistical modeling may be needed, depending how PROFIBUS
> behaves under load - what happens if another station is transmitting a very
> large packet at the time you need to send your packet, etc etc..)
>
> Step 2 is doing some userspace benchmarking of your response code - can the
> target hardware do whatever processing is needed in the time allowed (remember
> to subtract off any hardware-imposed latency like your PROFIBUS or your
> RS485-USB converter).  This can be easy to meet if you have a beefy CPU and
> just need to check the values of 3 bytes, add 2 other bytes together, and send
> the result.  On the other hand, if you're on a low-end ARM and need to do a
> 512x512 FFT - the Realtime Gods may not smile favorably on your endeavor.
>
> If your project is still alive at this point, *now* you start asking stuff like
> realtime scheduling for your kernel thread, how to reduce interrupt
> latency, and so on....
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies