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

[Tom B. <tb...@ba...>]

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...)


 +      _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...

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

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.

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 :-(

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 "{" .

----
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 like the way you handled the two packet read :-) in
phidgetInterfaceKit888Read (the whole of which looks good).

-Tom