libphidget-devel Mailing List for Phidget Library
Status: Alpha
Brought to you by:
jstrohm
Menu
▾
▴
libphidget-devel — Mailing list for developers of libphidget
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(134) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(23) |
Jul
(11) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Chris S. <str...@li...> - 2004-08-02 21:13:29
|
Wonderful! Tom, I read your project description in a past post. Mind me asking some electrical related questions offlist? I'm very interested in using the IK's in an automotive project.. but I'm not 100% sure on integrating the 12V into 5V. Thanks, -Chris Tom Brown wrote: >On Mon, 2 Aug 2004, Chris Strandt wrote: > > > >>Sourceforge shows no activity on this mailing list since 2003... just >>wanted to email and see what the status of the code in the cvs >>repository is. I have downloaded it, and gotten some of it to work.. >>but have had no luck with the 8/8/8 interface kit. >> >>I would like to add to this code, but will need assistance. I'm pretty >>much a newbie with C and C++. >> >> > >It was working :-) but then it seemed like it wasn't :-( ... > >my ITX box (the target environment) has been sitting on my desk since that >CVS activity, despite the fact that it was bought for autocross and we're >in the middle of the season. I'll see if I can find some time to dust it >off. > >-Tom > > > >>Thanks, >>-Chris >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by OSTG. Have you noticed the changes on >>Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, >>one more big change to announce. We are now OSTG- Open Source Technology >>Group. Come see the changes on the new OSTG site. www.ostg.com >>_______________________________________________ >>Libphidget-devel mailing list >>Lib...@li... >>https://lists.sourceforge.net/lists/listinfo/libphidget-devel >> >> >> > >---------------------------------------------------------------------- >tb...@Ba... | "The Internet is a world of ends. You're at one >http://BareMetal.com/ | end, and everybody and everything else are at the >web hosting since '95 | other ends." - http://www.worldofends.com/ > > > >------------------------------------------------------- >This SF.Net email is sponsored by OSTG. Have you noticed the changes on >Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, >one more big change to announce. We are now OSTG- Open Source Technology >Group. Come see the changes on the new OSTG site. www.ostg.com >_______________________________________________ >Libphidget-devel mailing list >Lib...@li... >https://lists.sourceforge.net/lists/listinfo/libphidget-devel > > |
|
From: Tom B. <tb...@ba...> - 2004-08-02 20:34:08
|
On Mon, 2 Aug 2004, Chris Strandt wrote: > Sourceforge shows no activity on this mailing list since 2003... just > wanted to email and see what the status of the code in the cvs > repository is. I have downloaded it, and gotten some of it to work.. > but have had no luck with the 8/8/8 interface kit. > > I would like to add to this code, but will need assistance. I'm pretty > much a newbie with C and C++. It was working :-) but then it seemed like it wasn't :-( ... my ITX box (the target environment) has been sitting on my desk since that CVS activity, despite the fact that it was bought for autocross and we're in the middle of the season. I'll see if I can find some time to dust it off. -Tom > > Thanks, > -Chris > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Libphidget-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libphidget-devel > ---------------------------------------------------------------------- tb...@Ba... | "The Internet is a world of ends. You're at one http://BareMetal.com/ | end, and everybody and everything else are at the web hosting since '95 | other ends." - http://www.worldofends.com/ |
|
From: Chris S. <str...@li...> - 2004-08-02 20:00:15
|
Sourceforge shows no activity on this mailing list since 2003... just wanted to email and see what the status of the code in the cvs repository is. I have downloaded it, and gotten some of it to work.. but have had no luck with the 8/8/8 interface kit. I would like to add to this code, but will need assistance. I'm pretty much a newbie with C and C++. Thanks, -Chris |
|
From: Loic D. <lo...@gn...> - 2003-10-16 18:29:12
|
Hi, Here is a patch against the current libphidgets CVS tree to add support for the following devices: idVendor 0x06c2 idProduct 0x0052 bcdDevice 1.00 iManufacturer 1 Phidgets Inc. iProduct 2 PhidgetTextLCD iSerial 3 01559 idVendor 0x0925 idProduct 0x8101 bcdDevice 0.02 iManufacturer 1 GLAB Chester iProduct 2 PhidgetServo iSerial 3 00389 It now works fine (says ./phidgets_c TEXTLCD & ./servo_example ;-) under GNU/Linux, provided you de-activate the hid module. There may be a way to use libusb while the hid module is in place. Cheers, Index: ChangeLog =================================================================== RCS file: /cvsroot/libphidget/libphidget/ChangeLog,v retrieving revision 1.2 diff -u -r1.2 ChangeLog --- ChangeLog 7 Sep 2002 20:12:29 -0000 1.2 +++ ChangeLog 16 Oct 2003 18:01:58 -0000 @@ -0,0 +1,8 @@ +Thu Oct 16 19:49:27 2003 Loic Dachary <lo...@gn...> + + * src/libphidget/phidget.c (phidgetTextLCD*): Add support for 0x06C2 / 0x0052 + +Thu Oct 16 14:01:50 2003 Loic Dachary <lo...@gn...> + + * src/libphidget/phidget.c (phidgetSingleServo): Add support for 0x0925 / 0x8101 + Index: src/libphidget/phidget.c =================================================================== RCS file: /cvsroot/libphidget/libphidget/src/libphidget/phidget.c,v retrieving revision 1.36 diff -u -r1.36 phidget.c --- src/libphidget/phidget.c 15 Aug 2003 02:43:29 -0000 1.36 +++ src/libphidget/phidget.c 16 Oct 2003 18:01:58 -0000 @@ -33,6 +33,100 @@ enum ELPError _libPhidgetError = LPE_NONE; /**< Last lib phidget error */ +/* + * Phidgets Protocol specific values for LCD screens + */ +#define PHIDGET_LCD_PROTOCOL_ESCAPE 0x00 /* If next value in buffer is 0x01 or 0x02, + it will not be interpreted as a + CONTROL_MODE or DATA_MODE switch. */ +#define PHIDGET_LCD_PROTOCOL_CONTROL_MODE 0x01 /* The next values in the buffer are + interpreted according to the + instruction set of the LCD screen + (HD44780 for instance). */ +#define PHIDGET_LCD_PROTOCOL_DATA_MODE 0x02 /* The next values in the buffer are + interpreted as characters to be + written on the screen. */ +#define PHIDGET_LCD_PROTOCOL_BUFFER_SIZE 8 /* Each USB packet must contain exactly + 8 bytes. */ +#define PHIDGET_LCD_PROTOCOL_LENGTH_INDEX 7 /* The number of valid bytes in the packet + must be located in the 7th byte of the + packet. */ +/* + * phidgetDevice->type->vendorID == 0x06C2 && phidgetDevice->type->productID == 0x0052 + * http://www.eio.com/hd44780.pdf page 191 + * http://www.doc.ic.ac.uk/~ih/doc/lcd/pc_example/ + * + * Constants for register values. + */ + +/* + * Turning the backlight of the HD44780 screen is done in a way that + * does not match the LCD_PROTOCOL above. Light is controled by + * black magic ;-) + */ +#define PHIDGET_HD44780_BYTE_0_BACKLIGHT_TURN_ON 0x01 +#define PHIDGET_HD44780_BYTE_7_BACKLIGHT_TURN_ON 0x11 +#define PHIDGET_HD44780_BYTE_0_BACKLIGHT_TURN_OFF 0x00 +#define PHIDGET_HD44780_BYTE_7_BACKLIGHT_TURN_OFF 0x11 + +#define HD44780_CHARACTERS_PER_LINE 20 /* One or two 20 characters lines. */ + +// HD44780 Instruction Set DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0 +// ======================= === === === === === === === === +#define HD44780_CLEAR_DISPLAY 0x01 // 0 0 0 0 0 0 0 1 +#define HD44780_RETURN_HOME 0x02 // 0 0 0 0 0 0 1 * +#define HD44780_SET_ENTRY_MODE 0x04 // 0 0 0 0 0 1 I/D S +#define HD44780_SET_DISPLAY 0x08 // 0 0 0 0 1 D C B +#define HD44780_SET_CURSOR_AND_DISPLAY_SHIFT 0x10 // 0 0 0 1 S/C R/L * * +#define HD44780_SET_FUNCTION 0x20 // 0 0 1 DL N F * * +#define HD44780_SET_CGRAM_ADDRESS 0x40 // 0 1 A A A A A A +#define HD44780_SET_DDRAM_ADDRESS 0x80 // 1 A A A A A A A + +// HD44780 Parameters +// ================== +// N.B. explicit values for EVERY corresponding parameter +// ==== MUST be passed each time any instruction is used + +// Set_Entry_Mode +// ============== +#define HD44780_DECREMENT_ADDRESS 0x00 // . . . . . . 0 . +#define HD44780_INCREMENT_ADDRESS 0x02 // . . . . . . 1 . + +#define HD44780_SHIFT_DISPLAY_OFF 0x00 // . . . . . . . 0 +#define HD44780_SHIFT_DISPLAY_ON 0x01 // . . . . . . . 1 + +// Set_Display +// =========== +#define HD44780_DISPLAY_OFF 0x00 // . . . . . 0 . . +#define HD44780_DISPLAY_ON 0x04 // . . . . . 1 . . + +#define HD44780_CURSOR_OFF 0x00 // . . . . . . 0 . +#define HD44780_CURSOR_ON 0x02 // . . . . . . 1 . + +#define HD44780_BLINK_OFF 0x00 // . . . . . . . 0 +#define HD44780_BLINK_ON 0x01 // . . . . . . . 1 + +// Set_Cursor_and_Display_Shift +// ============================ +#define HD44780_CURSOR 0x00 // . . . . 0 . . . +#define HD44780_DISPLAY_AND_CURSOR 0x08 // . . . . 1 . . . + +#define HD44780_LEFT 0x00 // . . . . . 0 . . +#define HD44780_RIGHT 0x04 // . . . . . 1 . . + +// Set_Function +// ============ +#define HD44780_DATA_LENGTH_4 0x00 // . . . 0 . . . . +#define HD44780_DATA_LENGTH_8 0x10 // . . . 1 . . . . + +#define HD44780_ONE_DISPLAY_LINE 0x00 // . . . . 0 . . . +#define HD44780_TWO_DISPLAY_LINES 0x08 // . . . . 1 . . . + +#define HD44780_FONT_5X7 0x00 // . . . . . 0 . . +#define HD44780_FONT_5X10 0x04 // . . . . . 1 . . + +#define HD44780_LINE2_OFFSET 0x40 + /** * Phidget description informatioin. \a deviceClass is specially useful in determining what type of phidget this is. * <b>You should never access any of ht edata members directly.</b> @@ -938,12 +1032,17 @@ _registerDeviceType("QuadServo .1 Degree", 0x06C2, 0x0038, LP_QUAD_SERVO); _registerDeviceType("UniServo .1 Degree", 0x06C2, 0x0039, LP_UNI_SERVO); + _registerDeviceType("UniServo .1 Degree", 0x0925, 0x8101, LP_UNI_SERVO); _registerDeviceType("Interface Kit 4/8/8", 0x0925, 0x8201, LP_INTERFACE_KIT_488); _registerDeviceType("Interface Kit 4/8/8", 0x06C2, 0x0040, LP_INTERFACE_KIT_488); _registerDeviceType("Interface Kit 4/8/8", 0x06C2, 0x0045, LP_INTERFACE_KIT_888); _registerDeviceType("Interface Kit 8/8/0", 0x06C2, 0x0041, LP_INTERFACE_KIT_880); _registerDeviceType("Phidget LCD", 0x06C2, 0x0041, LP_INTERFACE_KIT_880); _registerDeviceType("PhidgetTextLCD ECMA1010 Ver 1.0", 0x06C2, 0x0050,LP_TEXT_LCD); + /* Specifications for the line below at + http://www.eio.com/hd44780.pdf + http://home.iae.nl/users/pouweha/lcd/lcd.shtml */ + _registerDeviceType("PhidgetTextLCD", 0x06C2, 0x0052,LP_TEXT_LCD); _registerDeviceType("RFID VID/PID", 0x06C2, 0x0030, LP_RFID); _registerDeviceType("8-AdvancedServo", 0x06C2, 0x003B, LP_8WAY_SERVO); //_registerDeviceType("Interface Kit 32-32-0", 0x06C2, 0x0042, LP_INTERFACE_KIT); @@ -1282,9 +1381,8 @@ */ enum ELPError phidgetSingleServo(struct phidget *phidgetDevice, float percent) { - int _min=230,_max=(int) (180 * 10.6f + 230)+_min; - int pulse; char buffer[6] = { 0 }; + int buffer_size; DBG("phidgetSingleServo"); @@ -1297,21 +1395,41 @@ if (phidgetDevice->type->deviceClass != LP_UNI_SERVO) return (_error(LPE_WRONG_PHIDGET_CLASS_TYPE)); - //pulse = (int) (((percent) * 180) * 10.6f + 230); + if(phidgetDevice->type->vendorID == 0x0925 && phidgetDevice->type->productID == 0x8101) { + /* + * idVendor 0x0925 + * idProduct 0x8101 + * bcdDevice 0.02 + * iManufacturer 1 GLAB Chester + * iProduct 2 PhidgetServo + * http://sourceforge.net/docman/display_doc.php?docid=12651&group_id=60607 + */ + buffer[0] = 0; /* Index of servo : always 0 on single servo */ + buffer[1] = (int)(percent * 255); /* Semantic is unclear. */ + + buffer_size = 2; + } else { + int _min=230,_max=(int) (180 * 10.6f + 230)+_min; + int pulse; + + //pulse = (int) (((percent) * 180) * 10.6f + 230); + + if (phidgetDevice->extraData!=NULL) + { + int *temp=(int *)phidgetDevice->extraData; + _min=temp[0]; + _max=temp[1]; + } + //pulse = (int) (((percent) * 180) * 10.6f + 230); + pulse=(percent*(_max-_min))+_min; - if (phidgetDevice->extraData!=NULL) - { - int *temp=(int *)phidgetDevice->extraData; - _min=temp[0]; - _max=temp[1]; - } - //pulse = (int) (((percent) * 180) * 10.6f + 230); - pulse=(percent*(_max-_min))+_min; + buffer[0] = pulse % 256; + buffer[1] = (pulse / 256); - buffer[0] = pulse % 256; - buffer[1] = (pulse / 256); + buffer_size = 6; + } - return (phidgetWrite(phidgetDevice, buffer, sizeof(buffer))); + return (phidgetWrite(phidgetDevice, buffer, buffer_size)); } /** @@ -1834,10 +1952,13 @@ */ enum ELPError phidgetTextLCDClear(struct phidget *phidgetDevice) { - phidgetTextLCDWrite(phidgetDevice,0,0," "); - phidgetTextLCDWrite(phidgetDevice,1,0," "); - phidgetTextLCDWrite(phidgetDevice,2,0," "); - phidgetTextLCDWrite(phidgetDevice,3,0," "); + phidgetTextLCDWrite(phidgetDevice,0,0," "); + phidgetTextLCDWrite(phidgetDevice,1,0," "); + if(!(phidgetDevice->type->vendorID == 0x06C2 && phidgetDevice->type->productID == 0x0052)) { + + phidgetTextLCDWrite(phidgetDevice,2,0," "); + phidgetTextLCDWrite(phidgetDevice,3,0," "); + } } /** @@ -1845,13 +1966,29 @@ */ enum ELPError phidgetTextLCDOn(struct phidget *phidgetDevice) { - char buffer[8]; + char buffer[PHIDGET_LCD_PROTOCOL_BUFFER_SIZE] = { 0 }; + int i = 0; + + if(phidgetDevice->type->vendorID == 0x06C2 && phidgetDevice->type->productID == 0x0052) { + buffer[i++] = HD44780_SET_FUNCTION | HD44780_DATA_LENGTH_8 | HD44780_TWO_DISPLAY_LINES | HD44780_FONT_5X7; + buffer[i++] = PHIDGET_LCD_PROTOCOL_ESCAPE; + buffer[i++] = HD44780_CLEAR_DISPLAY; + buffer[i++] = HD44780_SET_DISPLAY | HD44780_DISPLAY_ON | HD44780_CURSOR_ON | HD44780_BLINK_ON; + buffer[PHIDGET_LCD_PROTOCOL_LENGTH_INDEX] = i; + + phidgetWrite(phidgetDevice,buffer,PHIDGET_LCD_PROTOCOL_BUFFER_SIZE); + + memset(buffer, '\0', PHIDGET_LCD_PROTOCOL_BUFFER_SIZE); + buffer[0] = PHIDGET_HD44780_BYTE_0_BACKLIGHT_TURN_ON; + buffer[7] = PHIDGET_HD44780_BYTE_7_BACKLIGHT_TURN_ON; + } else { + buffer[i++] = 0x69; // 0: 0 1 1 0 1 0 0 1 <- System Set, 4 lines, Use CGRAM + buffer[i++] = 0x31; // 0: 0 0 1 1 0 0 0 1 <- Display ON/OFF, Display ON + buffer[i++] = 0x42; // 0: 0 1 0 0 0 0 1 0 <- Power Save, Oscillator Circuit ON + buffer[7] = 3; + } - buffer[0] = 0x69; // 0: 0 1 1 0 1 0 0 1 <- System Set, 4 lines, Use CGRAM - buffer[1] = 0x31; // 0: 0 0 1 1 0 0 0 1 <- Display ON/OFF, Display ON - buffer[2] = 0x42; // 0: 0 1 0 0 0 0 1 0 <- Power Save, Oscillator Circuit ON - buffer[7] = 3; - return(phidgetWrite(phidgetDevice,buffer,8)); + return(phidgetWrite(phidgetDevice,buffer,PHIDGET_LCD_PROTOCOL_BUFFER_SIZE)); } /** @@ -1859,12 +1996,23 @@ */ enum ELPError phidgetTextLCDOff(struct phidget *phidgetDevice) { - char buffer[8]; + char buffer[PHIDGET_LCD_PROTOCOL_BUFFER_SIZE] = { 0 }; + int i = 0; - buffer[0] = 0x30; // 0: 0 0 1 1 0 0 0 0 <- Display ON/OFF, Display ON - buffer[1] = 0x40; // 0: 0 1 0 0 0 0 0 0 <- Power Save, Oscillator Circuit ON - buffer[7] = 2; - return(phidgetWrite(phidgetDevice,buffer,8)); + if(phidgetDevice->type->vendorID == 0x06C2 && phidgetDevice->type->productID == 0x0052) { + buffer[0] = PHIDGET_HD44780_BYTE_0_BACKLIGHT_TURN_OFF; + buffer[7] = PHIDGET_HD44780_BYTE_7_BACKLIGHT_TURN_OFF; + phidgetWrite(phidgetDevice,buffer,PHIDGET_LCD_PROTOCOL_BUFFER_SIZE); + memset(buffer, '\0', PHIDGET_LCD_PROTOCOL_BUFFER_SIZE); + + buffer[i++] = HD44780_SET_DISPLAY | HD44780_DISPLAY_OFF; + } else { + buffer[i++] = 0x30; // 0: 0 0 1 1 0 0 0 0 <- Display ON/OFF, Display ON + buffer[i++] = 0x40; // 0: 0 1 0 0 0 0 0 0 <- Power Save, Oscillator Circuit ON + } + buffer[PHIDGET_LCD_PROTOCOL_LENGTH_INDEX] = i; + + return(phidgetWrite(phidgetDevice,buffer,PHIDGET_LCD_PROTOCOL_BUFFER_SIZE)); } /** @@ -1878,38 +2026,46 @@ { int pos=0,t,len,tc; unsigned char temp[256],buffer[10]; + int max_len = 0; - //temp[pos++] = 0x69; // 0: 0 1 1 0 1 0 0 1 <- System Set, 4 lines, Use CGRAM - //temp[pos++] = 0x31; // 0: 0 0 1 1 0 0 0 1 <- Display ON/OFF, Display ON - //temp[pos++] = 0x42; // 0: 0 1 0 0 0 0 1 0 <- Power Save, Oscillator Circuit ON - temp[pos++] = 0x57; // 0: 0 1 0 1 0 1 1 1 <- RAM Address set to 010111 (23) - temp[pos++] = 0xB0; // Set the address pointer - temp[pos++] = 0x30 + row * 0x10 + 0x80+col; // set position we write to - temp[pos++] = 0x02; // Data mode + if(phidgetDevice->type->vendorID == 0x06C2 && phidgetDevice->type->productID == 0x0052) { + temp[pos++] = HD44780_SET_DDRAM_ADDRESS | (((row % 2) - 1) * HD44780_LINE2_OFFSET); + temp[pos++] = PHIDGET_LCD_PROTOCOL_DATA_MODE; + max_len = HD44780_CHARACTERS_PER_LINE; + } else { + //temp[pos++] = 0x69; // 0: 0 1 1 0 1 0 0 1 <- System Set, 4 lines, Use CGRAM + //temp[pos++] = 0x31; // 0: 0 0 1 1 0 0 0 1 <- Display ON/OFF, Display ON + //temp[pos++] = 0x42; // 0: 0 1 0 0 0 0 1 0 <- Power Save, Oscillator Circuit ON + temp[pos++] = 0x57; // 0: 0 1 0 1 0 1 1 1 <- RAM Address set to 010111 (23) + temp[pos++] = 0xB0; // Set the address pointer + temp[pos++] = 0x30 + row * 0x10 + 0x80+col; // set position we write to + temp[pos++] = 0x02; // Data mode + max_len = 12; + } // Write the string len=strlen(str); - if (len>12) len=12; + if (len>max_len) len=max_len; for (t=0;t<len;t++) temp[pos++]=str[t]; - temp[pos++] = 0x01; // back to command mode + temp[pos++] = PHIDGET_LCD_PROTOCOL_CONTROL_MODE; tc=0; for (t=0;t<pos;t++) { buffer[tc++]=temp[t]; - if (tc==7) + if (tc==PHIDGET_LCD_PROTOCOL_LENGTH_INDEX) { - buffer[7]=7; - phidgetWrite(phidgetDevice,buffer,8); + buffer[PHIDGET_LCD_PROTOCOL_LENGTH_INDEX]=tc; + phidgetWrite(phidgetDevice,buffer,PHIDGET_LCD_PROTOCOL_BUFFER_SIZE); tc=0; } } if (tc!=0) { - buffer[7]=tc; - phidgetWrite(phidgetDevice,buffer,8); + buffer[PHIDGET_LCD_PROTOCOL_LENGTH_INDEX]=tc; + phidgetWrite(phidgetDevice,buffer,PHIDGET_LCD_PROTOCOL_BUFFER_SIZE); } return (_error(LPE_NONE)); |
|
From: Tom B. <tb...@ba...> - 2003-07-29 00:45:29
|
On Mon, 28 Jul 2003, Mike Greffen wrote: > Hey, > I am having troubles retrieving the analog values from the 8/8/8 > phidget in linux. The phidget_read() subroutine is returning -1. Any > thoughts? anything in your system logs? probably /var/log/messages? > > Mike Greffen Phone : (403) 220-5729 > Institute for Space Research Fax : (403) 282-5016 cool... -Tom |
|
From: Mike G. <gr...@ph...> - 2003-07-29 00:19:36
|
Hey,
I am having troubles retrieving the analog values from the 8/8/8
phidget in linux. The phidget_read() subroutine is returning -1. Any
thoughts?
Thanks,
Mike
--
Mike Greffen Phone : (403) 220-5729
Institute for Space Research Fax : (403) 282-5016
Department of Physics and Astronomy
University of Calgary
Calgary, Alberta, CANADA T2N 1N4
|
|
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: 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: 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: 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: <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: 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: 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: 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: 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: 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: 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: 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: 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-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: <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 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: 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 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-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 |
