Re: Tricky USB device.
Bernd == Bernd Walter [EMAIL PROTECTED] writes: Bernd Yes - you must use 1 - there is only one out-endpoint. 0x81 is Bernd for receiving data and endpoint 0 is the mandandory control Bernd endpoint. Interrupt Endpoints are not variable in size. Both Bernd interrupt endpoints are 8 Bytes, so you must read and write Bernd exact 8 Bytes per transfer - 5 shouldn't work for USB compliant Bernd devices. I took your earlier advice and just opened ugen0.1 O_RDWR. I've tried sending 5 and 8 byte strings to it without effect. To make the 8 byte strings, I added spaces to the end of my 5 byte strings. I've also got a proper multitester now to verify operation. Bernd Depends on the device's firmware. I wouldn't be surprised if Bernd the whole device just hangs after receiving bogus data - it Bernd seems to be broken in many points. But it may block if the Bernd device has nothing to send. An easy way to check out is using Bernd tools like usbdevs -v and see if it hangs when accessing this Bernd device. usbdevs -v and udesc_dump both operate fine after trying this. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
Bernd == Bernd Walter [EMAIL PROTECTED] writes: Bernd Then the device is still working and just has nothing to send. Bernd Would be helpfull to know something about the protocol used on Bernd the endpoints. It's pretty simple. I'm sending (right now) MK255 and MK0 with 1 second sleeps in between. The device has 8 relays and I should be triggering them on and off (The MK command doesn't have output --- so I'm not looking for it). Here's a snippet from the manual: The relays may be SET ( ON ) or RESET ( OFF ) individually or as an 8 bit port. The relay commands include; SKn SETS ( ON ) relay specified by n ( n = 0-7 ) # of Bytes 3 Response NONE Example; SK2 ;closes contact K2 RKn RESETS ( OFF ) relay specified by n ( n= 0 - 7 ) # of Bytes 3 Response NONE Example; RK1 ;opens contact K1 MKddd Sets PORTK to decimal value ddd ( ddd= 0 to 255 ) ( K7-MSB, K0 = LSB ) # of Bytes 3 , 4 or 5 Response NONE Example; MK128 ;SETS K7, RESETS K0 - K6. RPKn Returns status of relay specified by n ( n= 0 - 7 ) # of Bytes 4 Response 1 byte ( 0 or 1 ) Example; RPK2 ;Relay K2 is closed. 1 ( response) PK Returns status of PORT K in decimal format. # of Bytes 2 Response 3 bytes ( 000 to 255 in decimal ) Example; PK ;K0 -K3 are SET ( ON ), K4-K7 are RESET ( OFF ). 015 ( response) Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
On Sat, Apr 09, 2005 at 05:48:43PM -0400, David Gilbert wrote: Bernd == Bernd Walter [EMAIL PROTECTED] writes: Bernd Then the device is still working and just has nothing to send. Bernd Would be helpfull to know something about the protocol used on Bernd the endpoints. It's pretty simple. I'm sending (right now) MK255 and MK0 with 1 second sleeps in between. The device has 8 relays and I should be triggering them on and off (The MK command doesn't have output --- so I'm not looking for it). Here's a snippet from the manual: The relays may be SET ( ON ) or RESET ( OFF ) individually or as an 8 bit port. The relay commands include; SKn SETS ( ON ) relay specified by n ( n = 0-7 ) # of Bytes 3 Response NONE Example; SK2 ;closes contact K2 [...] Sounds simple. Tried with lower case characters? Otherwise I would say sniff a working driver - for windows there is at least one good freeware USB sniffer avaiable. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
Bernd == Bernd Walter [EMAIL PROTECTED] writes:
Bernd Sounds simple. Tried with lower case characters? Otherwise I
Bernd would say sniff a working driver - for windows there is at
Bernd least one good freeware USB sniffer avaiable.
HA! Found the problem --- thank-you everyone. Aparently, this little
device expects a 0x01 as the first byte of any command. Heh. Works
now.
So if you need dry contact I/O ... this seems to work for FreeBSD...
/* Test the Ontrack ADU208 */
/* www.ontrak.net */
#include unistd.h
#include string.h
#include fcntl.h
#include err.h
#include sys/types.h
#include sys/uio.h
int main(int argc, char *argv[])
{
int bytes, fd;
char *s1 = \001MK255, *s2 = \001MK0, *s = s1, buf[256];
if((fd = open(/dev/ugen0.1, O_RDWR)) 0)
err(1, Cannot open device);
while(1)
{
bytes = write(fd, s, strlen(s));
printf(wrote %d bytes %s\n, bytes, s);
sleep(1);
if(s == s1)
s = s2;
else
s = s1;
}
return 0;
}
Dave.
--
|David Gilbert, Independent Contractor. | Two things can only be |
|Mail: [EMAIL PROTECTED]| equal if and only if they |
|http://daveg.ca | are precisely opposite. |
=GLO
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Tricky USB device.
I've got an OnTrak ADU208. It's a USB device that has 8 relays and 8 ttl inputs. The documentation says it uses two interupt endpoints ... one input and one output. It seems to expect small text commands. Now... firstly, uhid is probing it as uhid0: uhid0: www.ontrak.net ADU208 USB Relay I/O Interface, rev 1.10/0.00, addr 4, iclass 3/0 ... I don't know if this is hindering me. The usbhid* commands aren't particularly helpful. The port udesc_dump seems only to work on ugen devices ... and ugen doesn't pop up for this device. I suppose I need to know how to supress uhid ... or to make ugen show up. It would also be nice to know how to generically poke the interupt enpoints... Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
David, I've got an OnTrak ADU208. It's a USB device that has 8 relays and 8 ttl inputs. The documentation says it uses two interupt endpoints ... one input and one output. It seems to expect small text commands. ok Now... firstly, uhid is probing it as uhid0: uhid0: www.ontrak.net ADU208 USB Relay I/O Interface, rev 1.10/0.00, addr 4, iclass 3/0 ... I don't know if this is hindering me. The usbhid* commands aren't particularly helpful. The port udesc_dump seems only to work on ugen devices ... and ugen doesn't pop up for this device. how about getting usb hid descriptor, parsing and dumping it? check out libusbhid - man usbhid(3). it might be that all you need to do is to create hid report and send it to the device. libusbhid(3) will help you with that. I suppose I need to know how to supress uhid ... or to make ugen show up. It would also be nice to know how to generically poke the interupt enpoints... well comment out 'device uhid' from your kernel config and rebuilding the kernel should do the trick. max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
Maksim == Maksim Yevmenkin [EMAIL PROTECTED] writes: ... I don't know if this is hindering me. The usbhid* commands aren't particularly helpful. The port udesc_dump seems only to work on ugen devices ... and ugen doesn't pop up for this device. Maksim how about getting usb hid descriptor, parsing and dumping it? Maksim check out libusbhid - man usbhid(3). it might be that all you Maksim need to do is to create hid report and send it to the Maksim device. libusbhid(3) will help you with that. Tried that. The usb_get_report_desc() returns NULL. This is not a complicated device --- it's not even technically a human interface device. I suppose I need to know how to supress uhid ... or to make ugen show up. It would also be nice to know how to generically poke the interupt enpoints... Maksim well comment out 'device uhid' from your kernel config and Maksim rebuilding the kernel should do the trick. I wanted to try to avoid that since I use many USB devices, but it's a last resort kind-of-thing. The documentation for the device describes the interface as simply using the two interupt endpoints (read and write). Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
David, ... I don't know if this is hindering me. The usbhid* commands aren't particularly helpful. The port udesc_dump seems only to work on ugen devices ... and ugen doesn't pop up for this device. Maksim how about getting usb hid descriptor, parsing and dumping it? Maksim check out libusbhid - man usbhid(3). it might be that all you Maksim need to do is to create hid report and send it to the Maksim device. libusbhid(3) will help you with that. Tried that. The usb_get_report_desc() returns NULL. This is not a complicated device --- it's not even technically a human interface device. fine, so i presume usbhidctl(1) does not work on the device too. why did they made look like usb hid device then? I suppose I need to know how to supress uhid ... or to make ugen show up. It would also be nice to know how to generically poke the interupt enpoints... Maksim well comment out 'device uhid' from your kernel config and Maksim rebuilding the kernel should do the trick. I wanted to try to avoid that since I use many USB devices, but it's a last resort kind-of-thing. well, for what i know ugen(4) will only claim the device if no other usb device driver claimed it. so if the uhid(4) claimed it than (i assume) usb interface class on the device is set to the appropriate value. The documentation for the device describes the interface as simply using the two interupt endpoints (read and write). another way is to hack /sys/dev/usd/uhid.c and specifically ignore (usb vendor id, usb product id) for the device in the MATCH routine. something like if (uaa-vendor == uaa-product == ) return (UMATCH_NONE); max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
Maksim == Maksim Yevmenkin [EMAIL PROTECTED] writes: Maksim David, ... I don't know if this is hindering me. The usbhid* commands aren't particularly helpful. The port udesc_dump seems only to work on ugen devices ... and ugen doesn't pop up for this device. Maksim how about getting usb hid descriptor, parsing and dumping it? Maksim check out libusbhid - man usbhid(3). it might be that all you Maksim need to do is to create hid report and send it to the Maksim device. libusbhid(3) will help you with that. Tried that. The usb_get_report_desc() returns NULL. This is not a complicated device --- it's not even technically a human interface device. Maksim fine, so i presume usbhidctl(1) does not work on the device Maksim too. why did they made look like usb hid device then? Yeah... it appears to fail. I have no idea, but the guy at the company seemed to imply that he was just using a standard chip to drive the USB logic, so it may be a function of that. Maksim another way is to hack /sys/dev/usd/uhid.c and specifically Maksim ignore (usb vendor id, usb product id) for the device in the Maksim MATCH routine. something like Maksim if (uaa-vendor == uaa-product == ) return Maksim (UMATCH_NONE); Hrm. I thought that there might be some general bogon list, but that will certainly do. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
On Fri, Apr 08, 2005 at 12:56:16PM -0400, David Gilbert wrote: Maksim == Maksim Yevmenkin [EMAIL PROTECTED] writes: ... I don't know if this is hindering me. The usbhid* commands aren't particularly helpful. The port udesc_dump seems only to work on ugen devices ... and ugen doesn't pop up for this device. Maksim how about getting usb hid descriptor, parsing and dumping it? Maksim check out libusbhid - man usbhid(3). it might be that all you Maksim need to do is to create hid report and send it to the Maksim device. libusbhid(3) will help you with that. Tried that. The usb_get_report_desc() returns NULL. This is not a complicated device --- it's not even technically a human interface device. Then it really shouldn't have claimed to be one in the interface descriptor :( But the HID specification is more today than just _human_ interface. e.g. there are extensions for USV, ... I suppose I need to know how to supress uhid ... or to make ugen show up. It would also be nice to know how to generically poke the interupt enpoints... Maksim well comment out 'device uhid' from your kernel config and Maksim rebuilding the kernel should do the trick. I wanted to try to avoid that since I use many USB devices, but it's a last resort kind-of-thing. The documentation for the device describes the interface as simply using the two interupt endpoints (read and write). Has this device multiple interfaces? e.g. one HID and another as described. I often thought about getting ugen working at interface level too. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
Bernd == Bernd Walter [EMAIL PROTECTED] writes: Bernd Then it really shouldn't have claimed to be one in the Bernd interface descriptor :( But the HID specification is more today Bernd than just _human_ interface. e.g. there are extensions for Bernd USV, ... [...] Bernd Has this device multiple interfaces? e.g. one HID and another Bernd as described. I often thought about getting ugen working at Bernd interface level too. Here's the output of udesc_dump on it. Right now, using the current version of libusb (not the version from ports), I can use usb_interrupt_write(dev, 1, MK255, 5, 0) to send data to it --- and the data is sent --- at least lights on the USB hub flash. If I replace '1' with anything else, it doesn't accept it. However, it doesn't seem to have opened the relays. I'm also not entirely clear how/when to use usb_interrupt_read() ... as many of the commands listed in the manual return data, but usb_inerrupt_write() doesn't seem to allow for data to be returned, but following usb_interrupt_write(), the read will hang. ... so I'm somewhat at a loss, but I also can't find my multitester ... and will be fetching another one tonight. I'd appreciate any random knowledge anyone can summon on this topic. Standard Device Descriptor: bLength18 bDescriptorType01 bcdUSB 0110 bDeviceClass 00 bDeviceSubClass00 bDeviceProtocol00 bMaxPacketSize 8 idVendor 0a07 idProduct 00d0 bcdDevice iManufacturer 1 iProduct 2 iSerialNumber 3 bNumConfigurations 1 Configuration 0: Standard Configuration Descriptor: bLength 9 bDescriptorType 02 wTotalLength41 bNumInterface 1 bConfigurationValue 1 iConfiguration 4 bmAttributesa0 (remote-wakeup) bMaxPower 100 (200 mA) Standard Interface Descriptor: bLength9 bDescriptorType04 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass03 bInterfaceSubClass 00 bInterfaceProtocol 00 iInterface 5 HID Descriptor: bLength 9 bDescriptorType 21 bcdHID0100 bCountryCode 00 bNumDescriptors 1 bDescriptorType 22 wDescriptorLength 102 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 81 (in) bmAttributes 03 (Interrupt) wMaxPacketSize 8 bInterval10 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 01 (out) bmAttributes 03 (Interrupt) wMaxPacketSize 8 bInterval10 Codes Representing Languages by the Device: bLength 4 bDescriptorType 03 wLANGID[0] 0409 String (index 1): www.ontrak.net String (index 2): ADU208 USB Relay I/O Interface String (index 3): C02053 String (index 4): Cfg1 String (index 5): EP10In ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
David, Bernd Then it really shouldn't have claimed to be one in the Bernd interface descriptor :( But the HID specification is more today Bernd than just _human_ interface. e.g. there are extensions for Bernd USV, ... [...] Bernd Has this device multiple interfaces? e.g. one HID and another Bernd as described. I often thought about getting ugen working at Bernd interface level too. Here's the output of udesc_dump on it. Right now, using the current version of libusb (not the version from ports), I can use usb_interrupt_write(dev, 1, MK255, 5, 0) to send data to it --- and the data is sent --- at least lights on the USB hub flash. If I replace '1' with anything else, it doesn't accept it. However, it doesn't seem to have opened the relays. hmm... why even use libusb? cant you just fd = open(/dev/ugen0.1, O_RDWR); and then write(fd, MK255, 5) and read(fd, ...);. note: here i assume ugen0 is the device. I'm also not entirely clear how/when to use usb_interrupt_read() ... as many of the commands listed in the manual return data, but usb_inerrupt_write() doesn't seem to allow for data to be returned, but following usb_interrupt_write(), the read will hang. i'd guess you have to keep read pipe open at all times. that is what fd = open(/dev/ugen0.1, O_RDWR); will do - it will open both read and write pipes (because of O_RDWR). then you just write(fd, ...); read(fd, ...); max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
On Fri, Apr 08, 2005 at 03:32:56PM -0700, Maksim Yevmenkin wrote: hmm... why even use libusb? cant you just fd = open(/dev/ugen0.1, O_RDWR); and then write(fd, MK255, 5) and read(fd, ...);. note: here i assume ugen0 is the device. I'm also not entirely clear how/when to use usb_interrupt_read() ... as many of the commands listed in the manual return data, but usb_inerrupt_write() doesn't seem to allow for data to be returned, but following usb_interrupt_write(), the read will hang. i'd guess you have to keep read pipe open at all times. that is what fd = open(/dev/ugen0.1, O_RDWR); will do - it will open both read and write pipes (because of O_RDWR). then you just write(fd, ...); read(fd, ...); select(2) and non-blocking should work with ugen and interrupt endpoints too. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
On Fri, Apr 08, 2005 at 06:12:33PM -0400, David Gilbert wrote: Bernd Has this device multiple interfaces? e.g. one HID and another Bernd as described. I often thought about getting ugen working at Bernd interface level too. Here's the output of udesc_dump on it. Right now, using the current version of libusb (not the version from ports), I can use usb_interrupt_write(dev, 1, MK255, 5, 0) to send data to it --- and the data is sent --- at least lights on the USB hub flash. If I replace '1' with anything else, it doesn't accept it. However, it doesn't seem to have opened the relays. Yes - you must use 1 - there is only one out-endpoint. 0x81 is for receiving data and endpoint 0 is the mandandory control endpoint. Interrupt Endpoints are not variable in size. Both interrupt endpoints are 8 Bytes, so you must read and write exact 8 Bytes per transfer - 5 shouldn't work for USB compliant devices. Btw: you shouldn't use 0 as timeout value - this is OK under FreeBSD for having no timeout, but Linux understands it as 0 seconds and things fail. Having a timeout isn't bad anyway - you can still restart the transfer if you want. If portability is not an issue you should take Maksim's advice and directly use ugen* access. I'm also not entirely clear how/when to use usb_interrupt_read() ... as many of the commands listed in the manual return data, but usb_inerrupt_write() doesn't seem to allow for data to be returned, but following usb_interrupt_write(), the read will hang. Depends on the device's firmware. I wouldn't be surprised if the whole device just hangs after receiving bogus data - it seems to be broken in many points. But it may block if the device has nothing to send. An easy way to check out is using tools like usbdevs -v and see if it hangs when accessing this device. ... so I'm somewhat at a loss, but I also can't find my multitester ... and will be fetching another one tonight. I'd appreciate any random knowledge anyone can summon on this topic. Standard Device Descriptor: bLength18 bDescriptorType01 bcdUSB 0110 bDeviceClass 00 bDeviceSubClass00 bDeviceProtocol00 bMaxPacketSize 8 idVendor 0a07 idProduct 00d0 bcdDevice iManufacturer 1 iProduct 2 iSerialNumber 3 bNumConfigurations 1 Configuration 0: Standard Configuration Descriptor: bLength 9 bDescriptorType 02 wTotalLength41 bNumInterface 1 bConfigurationValue 1 iConfiguration 4 bmAttributesa0 (remote-wakeup) bMaxPower 100 (200 mA) Standard Interface Descriptor: bLength9 bDescriptorType04 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass03 bInterfaceSubClass 00 bInterfaceProtocol 00 iInterface 5 HID Descriptor: bLength 9 bDescriptorType 21 bcdHID0100 bCountryCode 00 bNumDescriptors 1 bDescriptorType 22 wDescriptorLength 102 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 81 (in) bmAttributes 03 (Interrupt) wMaxPacketSize 8 bInterval10 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 01 (out) bmAttributes 03 (Interrupt) wMaxPacketSize 8 bInterval10 OK - exactly one interface, which claims to be HID. I'm not familar with HID to say if it really is HID compatible. I personally would say that they took some sample code and just hacked it without really knowing what they do. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
Bernd Walter wrote: On Fri, Apr 08, 2005 at 06:12:33PM -0400, David Gilbert wrote: Bernd Has this device multiple interfaces? e.g. one HID and another Bernd as described. I often thought about getting ugen working at Bernd interface level too. Here's the output of udesc_dump on it. Right now, using the current version of libusb (not the version from ports), I can use usb_interrupt_write(dev, 1, MK255, 5, 0) to send data to it --- and the data is sent --- at least lights on the USB hub flash. If I replace '1' with anything else, it doesn't accept it. However, it doesn't seem to have opened the relays. Yes - you must use 1 - there is only one out-endpoint. 0x81 is for receiving data and endpoint 0 is the mandandory control endpoint. Interrupt Endpoints are not variable in size. Both interrupt endpoints are 8 Bytes, so you must read and write exact 8 Bytes per transfer - 5 shouldn't work for USB compliant devices. hmmm... i was always confused about bMaxPacketSize. i was thinking that it limits the size of one usb transaction, and it could take several usb transactions to transfer one data packet. for example i have a bluetooth usb dongle that has Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 81 (in) bmAttributes 03 (Interruput) wMaxPacketSize 16 bInterval1 and i certanly can receive data packets from this endpoint that are more (and less) then 16 bytes in size. so, i would guess (and i might be wrong) that it is ok to send/receive data packets that are not equal to bMaxPacketSize in size. max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
On Fri, Apr 08, 2005 at 04:47:43PM -0700, Maksim Yevmenkin wrote: Bernd Walter wrote: On Fri, Apr 08, 2005 at 06:12:33PM -0400, David Gilbert wrote: Bernd Has this device multiple interfaces? e.g. one HID and another Bernd as described. I often thought about getting ugen working at Bernd interface level too. Here's the output of udesc_dump on it. Right now, using the current version of libusb (not the version from ports), I can use usb_interrupt_write(dev, 1, MK255, 5, 0) to send data to it --- and the data is sent --- at least lights on the USB hub flash. If I replace '1' with anything else, it doesn't accept it. However, it doesn't seem to have opened the relays. Yes - you must use 1 - there is only one out-endpoint. 0x81 is for receiving data and endpoint 0 is the mandandory control endpoint. Interrupt Endpoints are not variable in size. Both interrupt endpoints are 8 Bytes, so you must read and write exact 8 Bytes per transfer - 5 shouldn't work for USB compliant devices. hmmm... i was always confused about bMaxPacketSize. i was thinking that it limits the size of one usb transaction, and it could take several usb transactions to transfer one data packet. It is a bit more complicated. For control endpoints packets transfers that are bigger than one packet can be transfered using multiple packets using a shortened last packet, which can be even of 0 length if the transfer exactly fits in packets. For bulk endpoints things can be handled specific to the protocol requirements - e.g. most serials don't track transfer borders. We have interrupt endpoints - you are right smaller than max packets are allowed - just checked the specs. The remaining is the same as for bulk endpoints, but interrupt endpoint are different in bus time calculations. for example i have a bluetooth usb dongle that has Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 81 (in) bmAttributes 03 (Interruput) wMaxPacketSize 16 bInterval1 and i certanly can receive data packets from this endpoint that are more (and less) then 16 bytes in size. so, i would guess (and i might be wrong) that it is ok to send/receive data packets that are not equal to bMaxPacketSize in size. As corrected above - you are really allowed to have smaller packets. But you can't have larger ones - however you can transfer multiple packets in one transaction, but this is not optimal speedwise as interrupt endpoints are laid out in a specific timeline. bInterval=1 means one packet per 1ms will be transfered and not more. Doing a transfer with e.g. 2 packets will take 1ms longer - even if the bus is idle in the meantime. This is because interrupt endpoints get garantied bus time. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
Maksim Yevmenkin wrote: Bernd Walter wrote: On Fri, Apr 08, 2005 at 06:12:33PM -0400, David Gilbert wrote: Bernd Has this device multiple interfaces? e.g. one HID and another Bernd as described. I often thought about getting ugen working at Bernd interface level too. Here's the output of udesc_dump on it. Right now, using the current version of libusb (not the version from ports), I can use usb_interrupt_write(dev, 1, MK255, 5, 0) to send data to it --- and the data is sent --- at least lights on the USB hub flash. If I replace '1' with anything else, it doesn't accept it. However, it doesn't seem to have opened the relays. Yes - you must use 1 - there is only one out-endpoint. 0x81 is for receiving data and endpoint 0 is the mandandory control endpoint. Interrupt Endpoints are not variable in size. Both interrupt endpoints are 8 Bytes, so you must read and write exact 8 Bytes per transfer - 5 shouldn't work for USB compliant devices. the device may accept 5 bytes of data. if it's feeling charitable. but you probably should send teh number of bytes suggested by the endpoint descriptor. that number is at least guaranteed to work. Hang on.. I'm trying to remember if the 8 includes the header.. if so then you probably only get 5 bytes of data space.. I need to go back to my USB book. From what I saw before, you may need to set the configuration number to 1 before it will do anything. so you may need to do a setConfiguration(1) then you should be able to read on the descriptor for endpoint 81. it should block until there is some activity to report on the switch. I'm guessing writing all 1s to endpoint 1 sets some leds or something. hmmm... i was always confused about bMaxPacketSize. i was thinking that it limits the size of one usb transaction, and it could take several usb transactions to transfer one data packet. for example i have a bluetooth usb dongle that has Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 81 (in) bmAttributes 03 (Interruput) wMaxPacketSize 16 bInterval1 and i certanly can receive data packets from this endpoint that are more (and less) then 16 bytes in size. so, i would guess (and i might be wrong) that it is ok to send/receive data packets that are not equal to bMaxPacketSize in size. yes bMaxPacketSize is the maximum single packet that the endpoint will handle, however many such transactions can be used to make up a USB request fronm the user.. max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
On Fri, Apr 08, 2005 at 06:06:30PM -0700, Julian Elischer wrote: Maksim Yevmenkin wrote: Bernd Walter wrote: On Fri, Apr 08, 2005 at 06:12:33PM -0400, David Gilbert wrote: Yes - you must use 1 - there is only one out-endpoint. 0x81 is for receiving data and endpoint 0 is the mandandory control endpoint. Interrupt Endpoints are not variable in size. Both interrupt endpoints are 8 Bytes, so you must read and write exact 8 Bytes per transfer - 5 shouldn't work for USB compliant devices. the device may accept 5 bytes of data. if it's feeling charitable. but you probably should send teh number of bytes suggested by the endpoint descriptor. that number is at least guaranteed to work. Hang on.. I'm trying to remember if the 8 includes the header.. The size is just the payload - I was just wrong, as interrupts transfers are allowed to be smaller. However the device should make use of 8 Byte packets or not say 8 Bytes at all. if so then you probably only get 5 bytes of data space.. I need to go back to my USB book. From what I saw before, you may need to set the configuration number to 1 before it will do anything. so you may need to do a setConfiguration(1) ugen will have done that already, otherwise it wouldn't know about the devnodes for the interrupt endpoints in the first configuration. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
