On Sun, Mar 16, 2014, at 07:06 PM, Michael Haberler wrote: > > Am 16.03.2014 um 23:48 schrieb Peter C. Wallace <[email protected]>: > > > I do know that index_enable is a pain to deal with anytime its not used in > > the standard way (because it is an I/O pin). It would be easier to use in > > these cases if it was done with two pins (or better still have index always > > enabled and have "index_detected" and "latched_count_at_index" pins. > > I see the problem, but not sure this is the issue when using an IO pin as a > changeable parameter
I agree - that is an unrelated issue, let's keep this thread about "pins as parameters" > the basic issue I see is: if you _could_ connect two IO pins without an > intervening signal, you would get undefined behavior because it is > unspecified which of the two 'O's gets precedence Actually, it is defined - whoever wrote last wins. As a general rule, real-time components write their OUT pins on every thread execution. As a general rule, real-time components do NOT write their IO pins on every thread execution. In particular, PID never writes them. Encoder only writes to index-enable to clear it after the index is detected. User space components are a little more messy, since they don't execute in any pre-defined order. I suspect that GUI widgets only write their pins when the widget is changed, but ultimately that is up to the widget author. Just as an electrical engineer who hooks two tri-state gates together is responsible for making sure only one is enabled at a time, a system builder who hooks two IO pins together is responsible for making sure they interact correctly. In the case of encoder, that is how the one-wire handshake is supposed to work. In the case of PID gains, the PID block will never write to the pin - no problem. (And it should be an IN pin!) > now you cant do that, you have to go through a signal, which gets precedence > over the pin value, meaning the signal destroys the pin default value, which > is counterproductive in the 'pin as parameter' use case The destruction of the default value is because we don't copy "dummy" to the signal, and that can be fixed as I suggested a couple messages ago. > one option would be to add a pin attribute (valid for HAL_IO pins only) say > HAL_DRIVING_VALUE which determines value resolution during linking - > basically it says this pin's value has priority over others linked to it: How is this attribute added? Who sets it? Is it done in the component source code? If so, you are assuming that the component author understands every use case for the component, and can choose the proper value. Or is it done in the HAL file somehow? If so, you are adding new commands and fields for the user to understand. > - if there is one HAL_IO pin with HAL_DRIVING_VALUE set in a 'net' statement, > it will determine the value of the signal linked to that signal (and > consequently of all the other HAL_IO pins) > - it is an error to link more than one HAL_IO pin with the HAL_DRIVING_VALUE > to a signal. > > This flag is considered only at 'net' time. > > This would retain the 'compiled in default value' requirement, and take care > of the 'netting destroys the pin default' issue Netting destroys default can be fixed by copying from dummy to signal on first link. If the user is netting two things, each of which has a compiled in default value, he gets to pick which one wins by the order of the pins in the net command. I just don't see how the HAL_DRIVING_VALUE attribute helps things. In essence, we already have that. An OUT pin has HAL_DRIVING_VALUE true. An IN pin has it false. Hal_lib already enforces the rule that only one driver can be linked together. IO pins are provided specifically for the case where there is a valid reason to link more than one driver together. -- John Kasunich [email protected] ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
