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

Reply via email to