Thread: [Libphidget-devel] libphidget newbie post...
Status: Alpha
Brought to you by:
jstrohm
Menu
▾
▴
libphidget-devel
|
From: Tom B. <tb...@ba...> - 2003-06-27 05:24:00
|
sorry for being impatient and not waiting a few days to see if there is any traffic on this list, but the sourceforge archives indicate zero traffic since september... I see Jack on the commit list is working on an 'LP_8WAY_SERVO' I'm trying to get the 888 interface kit up and running... anyhow, is anyone around I'm making slow progress... the DBG statements had to be defined and re-ordered to make my C compiler happy. --no-verify had to be deleted from a line in ./configure to get configure to run... I've added ( || interfacekit = 888) to a bunch of the 488 code and I'm now at the point where the code is trying to query the inputs on the device but I'm getting USB timeouts and I'm now substantially over my head (it has found and identified the device, so the USB layer would seem to be ok... it's probably just some 488 specific stuff in the command? Unfortunately I don't have any docs on the commands being sent in the USB datastream? [you here/hear Chester?]) ... will keep slugging at it... -Tom ---------------------------------------------------------------------- tb...@Ba... | Courage is doing what you're afraid to do. http://BareMetal.com/ | There can be no courage unless you're scared. | - Eddie Rickenbacker |
|
From: Tom B. <tb...@ba...> - 2003-06-27 05:44:15
|
sorry, missed some items that may be relevent... linux "dmesg" shows the following: usb.c: usbdevfs driver claimed interface caa63380 usb.c: ignoring set_interface for dev 9, iface 0, alt 0 usb.c: usbdevfs driver claimed interface caa63380 usb.c: ignoring set_interface for dev 9, iface 0, alt 0 usb_control/bulk_msg: timeout usbdevfs: USBDEVFS_BULK failed dev 9 ep 0x81 len 7 ret -110 I'm using the ik_example example ... note that the 1083 serial # is the same one reported by the linux kernel... usb.c: USB device number 7 default language ID 0x409 Manufacturer: Phidgets Inc. Product: PhidgetInterfaceKit SerialNumber: 01083 [root@home /home/tbrown/libusb/libphidget/src/examples]# strace -o tmpx -s 500 ./ik_example ik_example: code examples of how to communicate with interface kits Version 1.1 *** DEBUG *** : phidgetInit *** DEBUG *** : _clearDeviceTypes *** DEBUG *** : _registerDeviceType *** DEBUG *** : _registerDeviceType *** DEBUG *** : _registerDeviceType *** DEBUG *** : _registerDeviceType *** DEBUG *** : _registerDeviceType *** DEBUG *** : _registerDeviceType *** DEBUG *** : _registerDeviceType *** DEBUG *** : _registerDeviceType *** DEBUG *** : _registerDeviceType *** DEBUG *** : _registerDeviceType *** DEBUG *** : _registerDeviceType *** DEBUG *** : phidgetEvents *** DEBUG *** : _checkForSoftPhidgets *** DEBUG *** : Going thru all USB Busses *** DEBUG *** : Going thru each device on that bus *** DEBUG *** : _findDevice *** DEBUG *** : Is this device a phidget? - no *** DEBUG *** : _findDevice *** DEBUG *** : Is this device a phidget? - yes *** DEBUG *** : getting serial old fashioned way *** DEBUG *** : Get Serial *** DEBUG *** : _getSerial *** DEBUG *** : usb_open b0 Buffer:12 *** DEBUG *** : _addDevice *** DEBUG *** : _findDevice *** DEBUG *** : Is this device a phidget? - no *** DEBUG *** : _findDevice *** DEBUG *** : Is this device a phidget? - no *** DEBUG *** : Going thru each device on that bus *** DEBUG *** : _findDevice *** DEBUG *** : Is this device a phidget? - no *** DEBUG *** : _findDevice *** DEBUG *** : Is this device a phidget? - no *** DEBUG *** : Going thru phidgets *** DEBUG *** : _stateAttached *** DEBUG *** : phidgetGetPhidgets Interface Kit Controller found: 1083 Found interfacekit *** DEBUG *** : phidgetGetPhidgets *** DEBUG *** : phidgetOpen done 'CInterfaceKit'... built analog in *** DEBUG *** : phidgetRead whoa! usb_bulk_read() returned -1 bytes when we expected 7 Change:2.036505 Change:2.506664 Change:2.017647 Change:-1.999806 called kit.update() helper.h#127 const X &error (const X &) [with X = const phidget_type *] Exception:libphidget error >> Error reading bulk data from a phidget CPhidget.cc#45 int CPhidget::classType () Exception:libphidget error >> Error reading bulk data from a phidget *** DEBUG *** : phidgetClose exception:libphidget error >> Error reading bulk data from a phidget *** DEBUG *** : phidgetDeinit *** DEBUG *** : _clearDeviceTypes *** DEBUG *** : clearDevices On Thu, 26 Jun 2003, Tom Brown wrote: > > sorry for being impatient and not waiting a few days to see if there is > any traffic on this list, but the sourceforge archives indicate zero > traffic since september... > > I see Jack on the commit list is working on an 'LP_8WAY_SERVO' I'm trying > to get the 888 interface kit up and running... anyhow, is anyone around > > I'm making slow progress... the DBG statements had to be defined and > re-ordered to make my C compiler happy. --no-verify had to be deleted from > a line in ./configure to get configure to run... I've added ( || > interfacekit = 888) to a bunch of the 488 code and I'm now at the point > where the code is trying to query the inputs on the device but I'm getting > USB timeouts and I'm now substantially over my head (it has found and > identified the device, so the USB layer would seem to be ok... it's > probably just some 488 specific stuff in the command? Unfortunately I > don't have any docs on the commands being sent in the USB datastream? > [you here/hear Chester?]) ... will keep slugging at it... > > -Tom |
|
From: Vadim T. <vt...@fr...> - 2003-06-27 06:25:32
|
Hello Tom, > sorry for being impatient and not waiting a few days to see if there is > any traffic on this list, but the sourceforge archives indicate zero > traffic since september... Right decision :) > I'm making slow progress... the DBG statements had to be defined and > re-ordered to make my C compiler happy. --no-verify had to be deleted from > a line in ./configure to get configure to run... Never modify ./configure - it will be overwritten. Instead, modify configure.in and rerun ./bootstrap. Sorry, can't help you with the rest of the stuff as I don't have the hardware. > -Tom --vt |
|
From: Jack S. <js...@ja...> - 2003-06-27 06:45:47
|
Hey, good to here that someones trying out the code. The LP_8WAY_SERVO code is very much in the beta stage, but is very much at the top of my priorities getting fully functional. The current CVS version (as of a few days ago) was working for me, well at least it rotated when I told them to. Are you using the latest CVS release? On Fri, 2003-06-27 at 00:23, Tom Brown wrote: > sorry for being impatient and not waiting a few days to see if there is > any traffic on this list, but the sourceforge archives indicate zero > traffic since september... > > I see Jack on the commit list is working on an 'LP_8WAY_SERVO' I'm trying > to get the 888 interface kit up and running... anyhow, is anyone around > > I'm making slow progress... the DBG statements had to be defined and > re-ordered to make my C compiler happy. --no-verify had to be deleted from > a line in ./configure to get configure to run... I've added ( || > interfacekit = 888) to a bunch of the 488 code and I'm now at the point > where the code is trying to query the inputs on the device but I'm getting > USB timeouts and I'm now substantially over my head (it has found and > identified the device, so the USB layer would seem to be ok... it's > probably just some 488 specific stuff in the command? Unfortunately I > don't have any docs on the commands being sent in the USB datastream? > [you here/hear Chester?]) ... will keep slugging at it... > > -Tom > > ---------------------------------------------------------------------- > tb...@Ba... | Courage is doing what you're afraid to do. > http://BareMetal.com/ | There can be no courage unless you're scared. > | - Eddie Rickenbacker > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Libphidget-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libphidget-devel -- Jack Strohm <js...@ja...> |
|
From: Tom B. <tb...@ba...> - 2003-06-27 19:32:00
|
On 27 Jun 2003, Jack Strohm wrote: <snip> > Are you using the latest CVS release? yes. Although checking CVS out of sf.net seems to be painful (it doesn't seem to be very reliable, often refusing connections). ---- regarding conflicts with HID, I don't think there is a conflict with the 888 interface kit... I'm not getting the "usb.c: hid driver claimed interface d4d06980" type of message I get for a mouse or a UPS ... in fact, I'm seeing "usb.c: USB device 4 (vend/prod 0x6c2/0x45) is not claimed by any active driver" ... I'll keep reading (still pretty green), but I had been hoping that the HID-dev interface would work. The logic being that it would allow me to leverage the HID support. -Tom |
|
From: Jack S. <js...@ja...> - 2003-06-27 23:08:10
|
On Fri, 27 Jun 2003 3:55PM -0600, Tom Brown wrote: > On 27 Jun 2003, Jack Strohm wrote: > > <snip> > >> Are you using the latest CVS release? > > yes. Although checking CVS out of sf.net seems to be painful (it > doesn't > seem to be very reliable, often refusing connections). I noticed there cvs web based viewer said it was running off an archived copy. Maybe they are doing upgrades or something. > > ---- > > regarding conflicts with HID, I don't think there is a conflict with > the > 888 interface kit... I'm not getting the "usb.c: hid driver claimed > interface d4d06980" type of message I get for a mouse or a UPS ... in > fact, I'm seeing "usb.c: USB device 4 (vend/prod 0x6c2/0x45) is not > claimed by any active driver" ... I'll keep reading (still pretty > green), > but I had been hoping that the HID-dev interface would work. The logic > being that it would allow me to leverage the HID support. Well, first Chester sent me the specs so I will add them to the code this weekend and we can test how it works. Personally, I disliked the hid interface under linux (not well documented) but I really didn't spend mich time working with it. Since phidgets come in both hid and non hid flavors I decided to use libusb to work with them. Libusb runs on multiple platforms so if I port to mac someday it might just work. Anyway enough of my ramblings . . . -- Jack Strohm |
|
From: Tom B. <tb...@ba...> - 2003-06-29 10:19:05
|
On Thu, 26 Jun 2003, Tom Brown wrote:
>
> sorry, missed some items that may be relevent... linux "dmesg" shows the
> following:
>
> usb.c: usbdevfs driver claimed interface caa63380
> usb.c: ignoring set_interface for dev 9, iface 0, alt 0
> usb.c: usbdevfs driver claimed interface caa63380
> usb.c: ignoring set_interface for dev 9, iface 0, alt 0
> usb_control/bulk_msg: timeout
> usbdevfs: USBDEVFS_BULK failed dev 9 ep 0x81 len 7 ret -110
OK, I'm stuck. I can't get past the above. I've turned on all the
debugging in libusb and it's just saying the same thing. There
are some issues in the code (talking the endpoint 1 when it's
really 0x81), but libusb is correcting it with |= 0x80 .... It
took me a while to figure out why the kernel was reporting 0x81
when 0x01 was being specified. I added a usb_resetep after the
timeout, without it my mouse was locking up... which is _really_
wierd hhmm, maybe that is the problem... (I don't think so, the
absence or presence of hid and friends doesn't seem to be
relevent when things are working)
OK, after FAR too much messing around, it seems the buffer
lengths have to match the USB packet sizes perfectly... changing
the buffer from 7 to 8 chars in phidgetInterfaceKit488Read (which
I've hijacked) makes the code run... yeah! (I had already a 14 or
16 byte buffer...)
enum ELPError phidgetInterfaceKit488Read
{
// char buffer[7];
char buffer[8];
... that's _definately_ enough for tonight... (3am... yuck)
|
|
From: Jack S. <js...@ja...> - 2003-06-29 14:24:28
|
I'm still adding the new protocol to the code, I hope to have a test
version checked in tonight, wasn't feeling good yesterday so didn't make
much progress.
Yep, the input buffer has gone from 7 to 8 bytes. Here is the protocol
that chester sent me:
PhidgetInterfaceKit 8.0 Protocol
For PhidgetInterfaceKit 8/8/8
-------------------------------------------------------------------
PhidgetInterfaceKit 8/8/8, 8.0 PID: 0x06C2
PhidgetInterfaceKit 8.0 Protocol
For PhidgetInterfaceKit 8/8/8
-------------------------------------------------------------------
PhidgetInterfaceKit 8/8/8, 8.0 PID: 0x06C2
VID: 0x0045
-------------------------------------------------------------------
Output Packet
Output Packet
Length: 4 Bytes
Byte 0 = m_output_value;
Byte 1 = 0
Byte 2 = 0
Byte 3 = 0
Outputs 1-8 map onto m_output_value bits 0-7; a set bit indicates a CMOS
high (+5V),
a clear bit indicates a CMOS low (gnd)
-------------------------------------------------------------------
Input Packet
Length: 8 Bytes
The current state of this PhidgetInterfaceKit is too large to fit into a
single packet.
So Bit 1 of Byte 0 indicates whether this is a Packet.0 or Packet.1
In the case of Packet.0 (!(Byte_0 & 0x01)), this is the assignments.
Input_State 0-7 map onto Byte 1, bits 0-7, as shown.
m_inputvalue = Data[1];
12-Bit Sensor values are constructed from the packet as described:
newSensor[0] = ((unsigned char)Data[2] + ((unsigned char)Data[3] & 0x0f)
*
256);
newSensor[1] = ((unsigned char)Data[4] + ((unsigned char)Data[3] & 0xf0)
*
16);
newSensor[2] = ((unsigned char)Data[5] + ((unsigned char)Data[6] & 0x0f)
*
256);
newSensor[3] = ((unsigned char)Data[7] + ((unsigned char)Data[6] & 0xf0)
*
16);
In the case of Packet.1 (Byte_0 & 0x01), this is the assignments.
Input_State 0-7 map onto Byte 1, bits 0-7, as shown.
m_inputvalue = Data[1];
12-Bit Sensor values are constructed from the packet as described:
newSensor[4] = ((unsigned char)Data[2] + ((unsigned char)Data[3] & 0x0f)
*
256) * 4;
newSensor[5] = ((unsigned char)Data[4] + ((unsigned char)Data[3] & 0xf0)
*
16) * 4;
newSensor[6] = ((unsigned char)Data[5] + ((unsigned char)Data[6] & 0x0f)
*
256) * 4;
newSensor[7] = ((unsigned char)Data[7] + ((unsigned char)Data[6] & 0xf0)
*
16) * 4;
On Sun, 2003-06-29 at 05:18, Tom Brown wrote:
> On Thu, 26 Jun 2003, Tom Brown wrote:
>
> >
> > sorry, missed some items that may be relevent... linux "dmesg" shows the
> > following:
> >
> > usb.c: usbdevfs driver claimed interface caa63380
> > usb.c: ignoring set_interface for dev 9, iface 0, alt 0
> > usb.c: usbdevfs driver claimed interface caa63380
> > usb.c: ignoring set_interface for dev 9, iface 0, alt 0
> > usb_control/bulk_msg: timeout
> > usbdevfs: USBDEVFS_BULK failed dev 9 ep 0x81 len 7 ret -110
>
> OK, I'm stuck. I can't get past the above. I've turned on all the
> debugging in libusb and it's just saying the same thing. There
> are some issues in the code (talking the endpoint 1 when it's
> really 0x81), but libusb is correcting it with |= 0x80 .... It
> took me a while to figure out why the kernel was reporting 0x81
> when 0x01 was being specified. I added a usb_resetep after the
> timeout, without it my mouse was locking up... which is _really_
> wierd hhmm, maybe that is the problem... (I don't think so, the
> absence or presence of hid and friends doesn't seem to be
> relevent when things are working)
>
> OK, after FAR too much messing around, it seems the buffer
> lengths have to match the USB packet sizes perfectly... changing
> the buffer from 7 to 8 chars in phidgetInterfaceKit488Read (which
> I've hijacked) makes the code run... yeah! (I had already a 14 or
> 16 byte buffer...)
>
> enum ELPError phidgetInterfaceKit488Read
> {
> // char buffer[7];
> char buffer[8];
>
> ... that's _definately_ enough for tonight... (3am... yuck)
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> Libphidget-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libphidget-devel
--
Jack Strohm <js...@ja...>
|
|
From: Tom B. <tb...@ba...> - 2003-06-29 15:57:04
|
On 29 Jun 2003, Jack Strohm wrote:
> I'm still adding the new protocol to the code, I hope to have a test
> version checked in tonight, wasn't feeling good yesterday so didn't make
> much progress.
>
> Yep, the input buffer has gone from 7 to 8 bytes. Here is the protocol
> that chester sent me:
sorry, I have that (the protocol). I just didn't expect the
behaviour I got from the system for a buffer size mismatch.
AFAIK, I'm pretty much homefree from here, the rest should be
pretty trivial... just a case of finding another block of 5
hours...
While I'm here, my system isn't showing an output endpoint for
the 888 card... I don't have anything to compare it to... hhmm,
ok, it looks like we don't have a separate endpoint, e.g...
if (_isSoftPhidget(phidgetType(phidgetDevice))==0)
{
// If this isn't a soft phidget we use control messages so
ret=usb_control_msg(phidgetDevice->handle, 0x21, 0x09, 0x200, 0,
buffer, size, 5000);
}
else
{
// Only works for writing to soft phidgets
ret=usb_bulk_write(phidgetDevice->handle, 0x01,
(void *)buffer,size, 5000);
}
Is that conclusion/guess correct? The digitout outputs are
controlled with a control message?
is there somewhere were these magic constants like
"0x21, 0x09, 0x200" and the ones used to obtain the serial number
are described?
-Tom
|
|
From: <fit...@ph...> - 2003-06-29 16:04:31
|
Hi Tom, jack, vadim,
> sorry, I have that (the protocol). I just didn't expect the
> behaviour I got from the system for a buffer size mismatch.
> AFAIK, I'm pretty much homefree from here, the rest should be
> pretty trivial... just a case of finding another block of 5
> hours...
It's not just a buffer mismatch; it's the length of the packet.
> While I'm here, my system isn't showing an output endpoint for
> the 888 card... I don't have anything to compare it to... hhmm,
> ok, it looks like we don't have a separate endpoint, e.g...
>
> if (_isSoftPhidget(phidgetType(phidgetDevice))==0)
> {
> // If this isn't a soft phidget we use control messages so
> ret=usb_control_msg(phidgetDevice->handle, 0x21, 0x09, 0x200, 0,
> buffer, size, 5000);
> }
> else
> {
> // Only works for writing to soft phidgets
> ret=usb_bulk_write(phidgetDevice->handle, 0x01,
> (void *)buffer,size, 5000);
> }
>
> Is that conclusion/guess correct? The digitout outputs are
> controlled with a control message?
Very good.
> is there somewhere were these magic constants like
> "0x21, 0x09, 0x200" and the ones used to obtain the serial number
> are described?
These are all HID commands. 0x21,0x09,0x200 is a SetReport packet.
http://www.usb.org/developers/hidpage/
Chester
|
|
From: Tom B. <tb...@ba...> - 2003-06-29 16:31:08
|
On Sun, 29 Jun 2003 fit...@ph... wrote: > > Hi Tom, jack, vadim, > > > sorry, I have that (the protocol). I just didn't expect the > > behaviour I got from the system for a buffer size mismatch. > > AFAIK, I'm pretty much homefree from here, the rest should be > > pretty trivial... just a case of finding another block of 5 > > hours... > > It's not just a buffer mismatch; it's the length of the packet. well, in most socket/file-descriptor communications it wouldn't be such a big deal... having read through some of the kernel source, the libusb code, and of course libphidget.c ... I think I'm ok now. I know I've been remiss in not reading as much of the USB documentation as I should. > Very good. > > > is there somewhere were these magic constants like > > "0x21, 0x09, 0x200" and the ones used to obtain the serial number > > are described? > > These are all HID commands. 0x21,0x09,0x200 is a SetReport packet. > http://www.usb.org/developers/hidpage/ Thanks! > > Chester > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > Libphidget-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libphidget-devel > ---------------------------------------------------------------------- tb...@Ba... | Don't go around saying the world owes you a living; http://BareMetal.com/ | the world owes you nothing; it was here first. web hosting since '95 | - Mark Twain |
|
From: Jack S. <js...@ja...> - 2003-06-30 02:59:02
|
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. -- Jack Strohm |
|
From: Tom B. <tb...@ba...> - 2003-06-30 05:45:55
|
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
|
|
From: Vadim T. <vt...@fr...> - 2003-06-30 07:09:50
|
Hello Tom, > CVS is giving me grief (again), so I'll just scan the phidget.c changes > from the webcvs and give you my opinions... I'd suggest you subscribe to libphidget-cvs-commits and just get the changes as diffs so you can apply them even if the CVS is unreachable. --vt |
|
From: Jack S. <js...@ja...> - 2003-06-30 14:15:27
|
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...>
|
|
From: Jack S. <js...@ja...> - 2003-07-02 04:17:49
|
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 -- Jack Strohm <js...@ja...> |
|
From: Tom B. <tb...@ba...> - 2003-07-03 23:08:18
|
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. Digital out is not working correctly. 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.] 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. I think the API would benefit from a command to query value of either the 8 bit register, or the phidget directly. Comments? My apologies if the HID docs tell how to query the phidget, but they are more than a little intimidating :-( I'll go implement a static char register ... -Tom > > -- > Jack Strohm <js...@ja...> > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > Libphidget-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libphidget-devel > ---------------------------------------------------------------------- tb...@Ba... | Put all your eggs in one basket and http://BareMetal.com/ | WATCH THAT BASKET! web hosting since '95 | - Mark Twain |
|
From: Tom B. <tb...@ba...> - 2003-07-03 23:35:08
|
>
> I'll go implement a static char register ...
>
> -Tom
This seems to have the desired behaviour, I also added an 888 specific
check so as not to change the behaviour for the other phidgets...
-Tom
static unsigned char digitaloutputs = 0;
enum ELPError phidgetInterfaceKitWrite(struct phidget *phidgetDevice, int index,
{
char buffer[4];
if (phidgetDevice->type->deviceClass == LP_INTERFACE_KIT_888) {
if (value) {
digitaloutputs |= 1 << index;
} else {
digitaloutputs &= ~(1 << index);
}
buffer[0] = digitaloutputs;
} else {
buffer[0] = index+(value << 3);
}
buffer[1] = 0;
buffer[2] = 0;
buffer[3] = 0;
return(phidgetWrite(phidgetDevice,buffer,4));
}
|
|
From: Jack S. <js...@ja...> - 2003-07-04 06:33:18
|
On Thu, 2003-07-03 at 18:34, Tom Brown wrote:
> >
> > I'll go implement a static char register ...
> >
> > -Tom
>
> This seems to have the desired behaviour, I also added an 888 specific
> check so as not to change the behaviour for the other phidgets...
>
> -Tom
>
>
> static unsigned char digitaloutputs = 0;
>
> enum ELPError phidgetInterfaceKitWrite(struct phidget *phidgetDevice, int index,
> {
> char buffer[4];
>
> if (phidgetDevice->type->deviceClass == LP_INTERFACE_KIT_888) {
> if (value) {
> digitaloutputs |= 1 << index;
> } else {
> digitaloutputs &= ~(1 << index);
> }
> buffer[0] = digitaloutputs;
> } else {
> buffer[0] = index+(value << 3);
> }
> buffer[1] = 0;
> buffer[2] = 0;
> buffer[3] = 0;
> return(phidgetWrite(phidgetDevice,buffer,4));
> }
>
>
Yes, that will work temporarily, but a better solution (moving that buffer into struct phidget will work better.
This implementation will only support a single 888.
--
Jack Strohm <js...@ja...>
|
|
From: Tom B. <tb...@ba...> - 2003-07-04 10:10:33
|
> > Yes, that will work temporarily, but a better solution (moving that > buffer into struct phidget will work better. > > This implementation will only support a single 888. right. can't see the forest for the tree in front of me... ---------------------------------------------------------------------- tb...@Ba... | What I like about deadlines is the lovely http://BareMetal.com/ | whooshing they make as they rush past. web hosting since '95 | - Douglas Adams |
|
From: Tom B. <tb...@ba...> - 2003-07-04 05:21:50
|
> The api currently uses a set/clear bit function, but the phidget takes an
> 8 bit value ....
duh. It just occured to me that the _api_ "seems to" show a set/clear bit
function, but it takes a integer values, the code could be modified to
expect/understand an 8 bit value for an index of -1 (or 9) or something
like that. The old code:
buffer[0] = index+(value << 3);
really does seem to be using the bottom three bits to indicate a bit
position and the 4th bit to indicate a 1 or 0 ... so it seems to be bit
oriented.
In case my request for a method to query the phidget's status wasn't
clear... the main rational is that the application may have been started,
then stoped, then restarted. In this case, the phidget may have been
configured by the application and any change by libfidget risks throwing
away the existing config...
I'll try to shutup now until folks with more experience with the phigets
can speak.
-Tom
|
|
From: <fit...@ph...> - 2003-07-04 06:15:39
|
Hi, > In case my request for a method to query the phidget's status wasn't > clear... the main rational is that the application may have been started, > then stoped, then restarted. In this case, the phidget may have been > configured by the application and any change by libfidget risks throwing > away the existing config... > I'll try to shutup now until folks with more experience with the phigets > can speak. It would be possible to allow the output state to be queried through HID in the future. This is a firmware limitation, I never thought applications would need this. Chester |
|
From: Jack S. <js...@ja...> - 2003-07-04 06:32:01
|
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...> |
|
From: Jack S. <js...@ja...> - 2003-07-08 02:26:51
|
Tried to add support for digital output on the 888, someone try it out. On Tue, 2003-07-01 at 23:17, 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 -- Jack Strohm <js...@ja...> |
|
From: Jack S. <js...@ja...> - 2003-06-27 06:52:24
|
On Fri, 2003-06-27 at 00:23, Tom Brown wrote: > I see Jack on the commit list is working on an 'LP_8WAY_SERVO' I'm trying > to get the 888 interface kit up and running... anyhow, is anyone around Note to self, never respond to email at 2 in the morning, please ignore previous email. I see the number 8 and think Advanced Servo Phidget. Ok, let's try this again. Currently, been focusing on getting the 8 way servo phidget working. It's late so don't quote me on this, but I don't think I have an 888 IK to test with. I will talk to Chester about the protocol and see if I can get support added. If you don't mind being a tester for me we might get it working. Ok, off to sleep . . . |
Thanks for helping keep SourceForge clean.
X