On Thu, Jul 28, 2016 at 06:12:07PM +0200, Nicklas Karlsson wrote:
> Reading a unconnected pin should result at least in a warning. I guess
> this could be checked beforehand as soon as linuxcnc is started.
This is a change that would break virtually all existing HAL
configurations. For instance, run configs/sim/axis/axis.ini. In
whatever branch my current tree is in, only 43 out of 393 IN pins are
linked.
We had, and still have, simple rules that gives unconnected pins
a well-defined value: It is the value of the pin's "dummy signal". This
"dummy signal" can be driven with a value at several times:
* Since the original design of HAL:
* Automatically driven to zero / FALSE at pin creation time
* Explicitly driven to a default value by an assignment in the component
between pin creation time and the call to hal_ready()
* Explicitly driven to an appropriate constant value by explicit
"halcmd setp" after hal_ready() but before "halcmd start"
* Since the change to hal_link() / hal_unlink() in 2.6:
* Implicitly driven to the current (or at least recent[1]) value of
the previously-linked signal
I believe the rules for a never-connected pin are simple to explain and
they are good because they
* Eliminate the need for null pointer checks before pin dereference
(more because of the cognitive load for component developers, not
because of the number of cycles burned for null pointer checks)
* Allow components to give good default behavior (for instance, a
mode pin can default to a mode that is expected to serve a
plurality of users; a velocity pin can default to "no velocity",
and so forth)
* Allow configuration to a different, but constant, value without
the need to introduce a separate "constant" component and a signal
to carry that constant to the component with the input pin
Making pins NULL by default until linked to a signal means "halcmd setp"
can no longer be used to give a pin a value, and means that for even a
very simple linuxcnc configuration about 350 additional signals are
needed, which in turn would need to be driven by 350 new "constant"
component instances. Not to mention the number of lines of component
source to be rewritten with additional null pointer checks.
Jeff
[1] Since hal_unlink is not executing in realtime, there's no guarantee
that the signal value read at one point in hal_link is the value still
driven onto that signal at the moment it actually points the pin back to
its dummy signal
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
