Re: [Libphidget-devel] First stab at the 888 ik

[Jack S. <js...@ja...>]

On Thu, 2003-07-03 at 18:07, Tom Brown wrote:
> On 1 Jul 2003, Jack Strohm wrote:
> 
> > Ok, I made a few more changed.  For those that are CVS impaired I've put
> > a copy of the latest code at 
> > 
> > http://iris.homeip.net/~jstrohm/libphidget.tgz
> > 
> > Let me know how much of it works for the 888
> 
> ok, as I said off list, digital in and analog in continue to look good.

that's good.

> Digital out is not working correctly.

Don't expect that to work yet.

> The api currently uses a set/clear bit function, but the phidget takes an
> 8 bit value ....
> 
> The code below correctly _sets_ a single bit, but doing that resets all
> 7 other bits.
> 
> [whoops, I just realized, I'm messing with code that probably is working
> correctly for the other interface kits??, I guess we need a new function.]

Yep, the other interface kits work differently.  I'm going to modify
this function to send different data depending on the phidget type.

I have a void * in the phidget structure to store "private" data.  I
will use this to store the states of the outputs, and it will use that
(and update it) when this function is called so that we don't get
"resets" as described above.


>    enum ELPError phidgetInterfaceKitWrite(struct phidget *phidgetDevice, 
>      int index, int value )
>    {
> 	   char buffer[4];
> 
> 	   // TODO - This doesn't work for the 888 yet, need to
> 	   // rework some internal data structures to get it working.
> 
> 	   // isn't this horribly simplistic? don't we need to
> 	   // maintain a bitmap of the set bits? Either that or pass
> 	   // the responsibility for that to the application?
> 	   // afaik, the 8 bits of buffer[0] are the 8 outputs
> 
> 	   //buffer[0] = index+(value << 3);
> 	   buffer[0] = value << index;
> 	   buffer[1] = 0;
> 	   buffer[2] = 0;
> 	   buffer[3] = 0;
> 	   return(phidgetWrite(phidgetDevice,buffer,4));
>    }
> 
> all the comments but the TODO are mine. The simplest fix seems to
> be to maintain a byte containing the expected value in the
> phidget. If there is a command for querying the current value in
> the phidget, a better solution would be to query the phidget,
> then write out the updated bit mask. The best solution would
> probably be a combination.

Your comment above about maintaining the states of the set bits is what
I was talking about doing above.  I had planned for this already, just
have to implement.  So the function call won't change (and neither will
the C++ library that uses this function).

> 
> I think the API would benefit from a command to query value
> of either the 8 bit register, or the phidget directly.

I don't really need to query it, but I could see that be useful if it
was every implemented.

-- 
Jack Strohm <js...@ja...>