Minimum "on-time" for hal toggle pin

You have to be a little bit careful here. When doing a kernel trace on a modestly specced PC, we found the servo thread usually got it's job done in about 0.2 T then slept for about 0.8T.  So there is a lot of time that Linuxcnc is not looking. Some cycles will have more work to do than others. While the start of the period is defined by the servo thread frequency, no such timing is applied to when the thread goes to sleep. It just needs to be asleep before 1T +- jitter is up.

But in this instance, it's required to  interface with a userspace pin so there is no T to control timing. I'm not sure how long would be required but I suspect 2T would not be enough to guarantee it's actioned reliably.

For real time signals, 2T should be good enough (as rmu indicated you should not
run a system that gets real time errors)

In fact most LinuxCNC real time components (like software stepgens or the software encoder
component) depend of this being true.

If you have non-real time functions, there is no upper bound on response time so you
would be safer using some kind of handshaking.

@rmu You are absolutely right, by the time you have a jitter ~1T you got bigger problems to worry about, and you should not run a machine under those conditions.

My original assumption (possibly a wrong one) was that @beefy was questioning how to interface a microcontroller to a correctly configured and functioning HAL real-time thread. Obviously for some definition of "correctly" and "functioning" which I would suggest means Jitter << 1T. I maintain that the answer is pulse > 1T where the ">" represents the aggregated uncertainties within the system, which I am assuming to be well << 1T. Note that >1T is algorithmic, with pulse = 2T being perhaps the obvious first choice.

When discussing the subject we all moved the focus on the system jitter. On that subject, while I do agree with @rmu that we should avoid large jitter, I want to point out that it is not so simple, since LinuxCNC does not run on a hard real-time OS. Consequently, in the absence of a *guarantee* all we can do is to run one of the latency* tools for "a while" and hope that we get good-enough representative data.

The bottom line is that the pulse = 2T is a good suggestion.
Perhaps what threw me off was the ">" sign in the original ">2T" suggestion which I (perhaps wrongly) interpreted as an algorithmic suggestion rather than "make it 2T and you are good, and if it's more that is OK, too".

Cheers