Jeff Epler wrote: > On Wed, Oct 27, 2010 at 05:38:24PM +0100, Andy Pugh wrote: > >> On 27 October 2010 17:09, Jeff Epler<jep...@unpythonic.net> wrote: >> >> >>> It's a dirty trick and I'd rather see it get as little use as possible.. >>> >> Is there an easy, elegant way to make it less dirty? I can see many >> uses for it (encoders going automatically into counter-mode, bldc >> drivers knowing whether to use encoder or hall-sensor feedback spring >> to mind) >> > You're right. Either I shouldn't use the trick here, or other > components should feel free to use the trick. Which do we want to do? > > First, let me summarise what the trick *is*. After hal_pin_new returns, > the pin points at the internal "dummysig". The dummysig exists so that > it's always permitted to dereference a pin, regardless of whether a pin > is connected. > > When a pin is connected to any signal, the address it points to is some > other address than the dummysig. > > If the dummysig address is stored just after hal_pin_new, this enables: > * test in constant time and from a RT thread whether the pin is > connected to any signal > * generate a value internally onto the dummysig that is later read as > the pin's value when the pin is not connected to any signal > > There are some reasons to *not* use this trick in hal components: > * In the future we might see a way to change the design in a way that > makes the trick unusable (for instance, something that doesn't > require the dummysig at all) > * The hal lock is held during the time between hal_pin_new and the copy > I think this is supposed to say that the HAL lock is *not* held ... > of the dummysig address. Instead, the assumption that makes this > safe is that the only possible pin-linker is the same halcmd that is > waiting for this component to be ready. We might want to violate > this assumption sometime in the future (and you can probably violate > it now just by running two halcmds at the same time) > * The trick depends on whether a signal is connected, not whether a > signal with a writer is connected. So for instance, connecting a > signal and then scoping the signal will modify the component's > behavior. (thanks to SWP for identifying this problem) > > What other considerations (uses or problems) are there than the ones > I've identified? Shall we decide to use this trick freely, or to use it > not at all? If we decide to use it freely, should we create some kind > of API to make its use more explicit? > It seems reasonable to me to create an API for this. Something like pin_is_connected(something). At the moment, that can be a #define macro that tests for (something==&((halpin)something->dummysig)) (or whatever the correct spelling is). If it turns into an actual function call, or we add a flag to the pin struct that tells whether it's connected, has a writer, etc, the function can change.
In fact, a full set of functions might as well be defined: pin_has_reader() pin_has_writer() pin_is_connected() (has_writer() and has_reader() also imply is_connected()==true) Similar API functions for signals may be useful. Maybe not in RT components, but certainly in userland utilities. There may be an argument that these functions shouldn't exist - an IC doesn't know whether a pin is being used, or what it's being used for. It's just supposed to do its function(s) anyway. If there's a need for this knowledge inside a component (the equivalent of an IC in the HAL model), then maybe the design of the component is wrong. I guess my opinion is that we should add a full API or nothing at all :) - Steve ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers