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

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

On Mon, 2003-06-30 at 00:45, Tom Brown wrote:
> On Sun, 29 Jun 2003, Jack Strohm wrote:
> 
> > Ok, I commited my initial try at using the 888.
> > 
> > If you have code talking to the 888 send me a patch and I will merge it 
> > into mine, or if you want you can merge it in yourself and send me that 
> > patch.
> 
> CVS is giving me grief (again), so I'll just scan the phidget.c changes
> from the webcvs and give you my opinions... (I wish I'd noticed that
> phidget_c.c is pure C before writing my own from scratch...)

If you will try to describe your CVS problem to me I can try to help.  I
haven't had any issues recently.  

Yeah phidget_c is pure C.  I know a lot of people prefer C so I've tried
to keep that in mind in writing this.  The C++ code just adds some
features and simplifies handling the phidgets.    



> 
> 
>  +      _registerDeviceType("Interface Kit 4/8/8", 0x06C2, 0x0045, LP_INTERFACE_ KIT_888);
> 
> typo'd the name :-) 8/8/8 not 4/8/8
> 
>  +              // This weird ordering was used in the 488 phidget
>   +             // so I'm wondering if it is needed for the 888
> 
> No the 488 wierdness (digital in) isn't needed, the code you have should
> be correct although the == checks are completely unnecessary... And I'm
> not sure about the polarity... but walking over the pins with an ammeter
> (e.g. a short) shorting the inputs to ground produces resulting ones ...
> if that's the desired true/false (grounded = 1) then we're alright...

yep, that sounds right.  I'll fix the ordering.

> 
> oh, and you probably want to remove the *4 from the comment...
> (cosmetic)

Will do.  Might add it in the C++ code to make all the outputs look the
same (12 bit)

> 
> AFAICS, phidgetInterfaceKitWrite works fine for the 888  ... oh,
> hang on, only the first 3 outputs work...??  I guess I wasn't
> sufficiently diligent with my testing... will look at that later if you
> don't beat me to it.

yep, figured something like that would happen.  If I have time I'll take
a stab at it tonight.  


> sourceforge CVS is giving me grief again so I can't do the proper
> merge...
> 
> [root@home /home/tbrown/libusb/libphidget/src/libphidget]# cvs status !$
> cvs status phidget.c
> ===================================================================
> File: phidget.c         Status: Up-to-date
> 
>    Working revision:    1.30
>    Repository revision: 1.30
> /cvsroot/libphidget/libphidget/src/libphidget/phidget.c,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)
> 
> when clearly, you just checked in 1.31 ... go figure :-(

You've done a cvs update?


> one thing I forgot about, my compiler wanted all the DBG
> statements moved _after_ the variable declarations. I gather the
> C++ compiler is more flexible and allows you to declare variables
> anywhere, C doesn't... it wants all the variables to be declared
> immediately following an open brace "{" .

Yep, I'm using GCC and it's much more flexible but it should have given
me a warning about that.  I'll fix that today.


> ----
> oh, and I added some error handling and changed the endpoint in
> phidgetread to 0x81 ... the implementation is crud, but the
> better reporting idea is valid. Oh, and I'm no expert, but
> reseting the endpoint on a read failure seemed to help when I was
> having trouble, but that seems to be reflection on the Linux USB
> layer being not very good at cleaning itself up...
> 
>  enum ELPError phidgetRead(struct phidget *phidgetDevice, char *buffer, int size)
>  {
> +       int endpoint = 0x81; //TAB 
> +       int val;
>         DBG("phidgetRead");
>  
>         if (_libPhidgetInitialized == 0)
> @@ -1263,8 +1265,24 @@
>  
>         //if (usb_bulk_read(phidgetDevice->handle, 0x01, buffer, size, 5000) != 0)
>                 //return (_error(LPE_BULK_READ_ERROR));
> -       if (usb_bulk_read(phidgetDevice->handle, 0x01, buffer, size, 5000) != size)
> +
> +       //val = usb_bulk_read(phidgetDevice->handle, 0x01, buffer, size, 5000);
> +       // TAB at least for the 888, the endpoint is 0x81
> +       val = usb_bulk_read(phidgetDevice->handle, endpoint, buffer, size, 5000);
> +       if ( val != size) {
> +#ifdef DBG
> +               usb_resetep(phidgetDevice->handle, endpoint);
> +      printf("whoa! usb_bulk_read(%d,%x,buf,%d,5000) returned %d bytes when we expected %d\n",
> +                  phidgetDevice->handle, endpoint, size, val, size );
> +#endif
>                 return (_error(LPE_BULK_READ_ERROR));
> +       } else {
> +#ifdef DBG
> +      printf("yeah! usb_bulk_read(%d,%x,buf,%d,5000) returned %d bytes as expected!\n",
> +                  phidgetDevice->handle,0x01,size,val);
> +#endif
> +          
> +       }


I'll look at this when I'm more awake

> 
> I like the way you handled the two packet read :-) in
> phidgetInterfaceKit888Read (the whole of which looks good).
> /listinfo/libphidget-devel

Thanks!

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