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@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@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies