From: erbenton <erb...@co...> - 2003-12-10 00:13:50
|
Hi, I am new to the list. I browsed the archives and see references to usb_interrupt_read. What do i have to do to call that? It isnt in any of the files i downloaded (libusb-0.1.7.tar). I'm trying to get interrupt data from a tripplite UPS its an omnism1000usb model. The software you can download from their website is useless so i want to see if i can detect the power states of the UPS which is connected via USB. I i get it working I'll share the code of course. Also, f anyone has messed with this unit and has learned anything I would appreciate a copy of the info. Thanks Eric (FYI) Here is the output from lsusb: Bus 001 Device 002: ID 09ae:0001 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 Interface bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x09ae idProduct 0x0001 bcdDevice 0.01 iManufacturer 1 TRIPP LITE iProduct 2 TRIPP LITE OMNISM1000USB iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 34 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 MaxPower 60mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Devices bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.00 bCountryCode 0 bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 52 cannot get report descriptor Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type none wMaxPacketSize 8 bInterval 10 Language IDs: (length=4) 0409 English(US) |
From: <Mar...@om...> - 2006-05-31 13:30:46
|
Hello ! I found the problem with usb_interrupt_read. I passed 16 bytes buffer to the function which results in a -EINVAL at kernel 2.4.27. If only 8 Bytes are passed it works fine with 2.4.27 and 2.6.8. Greetings Martin |
From: Tim R. <ti...@pr...> - 2006-05-31 15:52:43
|
Mar...@om... wrote: >Hello ! > >I found the problem with usb_interrupt_read. I passed 16 bytes buffer to >the function which results in a -EINVAL at kernel 2.4.27. If only 8 Bytes >are passed it works fine with 2.4.27 and 2.6.8. > > Is this a low-speed device? Interrupt pipes on low speed devices can only handle 8 bytes per transfer. It's possible that the 2.4.27 kernel is not capable of chopping a request up into packet-sized chunks. I do have to say that, although I am a Linux advocate, USB support is perhaps the one key subsystem where Windows clearly has Linux beat all to heck. USB on Windows has been rock solid for 7 or 8 years, and I'm still seeing flakiness in Linux even on a 2.6.10 kernel. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
From: Lou <lou...@fi...> - 2008-07-23 16:34:31
|
This is with libusb-0.1-4. I'm trying to build a USB device. I was having problems, so I've temporarily excised my more complex code, and am now just repeatedly sending blocks of fixed data from it over endpoint 2, which is configured as an interrupt IN endpoint. It has a wMaxPacketSize of 64. On the host, I get (via usb_interrupt_read with a 64 byte buffer) the first packet. I get the number of bytes that the device sends, whether that is 64 or something smaller like 32. The next read times out. This is the same whether I'm sending 64 byte packets from the device or smaller ones. usbmon only shows me this, which just says the same thing I just did. dda0b2a0 1666872742 S Ii:059:02 -115 64 < dda0b2a0 1666879716 C Ii:059:02 0 32 = 48656c6c 6f20776f 726c6421 20205468 69732069 73206120 74657374 20776974 dda0b2a0 1666881961 S Ii:059:02 -115 64 < dda0b2a0 1671885517 C Ii:059:02 -2 0 In my device code, I see that the second packet has been sent, but the transmitter isn't giving me the go-ahead to write the third one, as the second one hasn't been acknowleged by the host. In case it matters, my device is on a SAM7S chip, but I suspect that whatever is up isn't at that level. I don't think I'm at the point where I need to worry about short/ZLPs yet. As I said, I have tried this with 64 byte packets with the same result (differing only in the number of bytes returned). What frightfully obvious thing am I overlooking? |
From: Tim R. <ti...@pr...> - 2008-07-23 16:55:06
|
Lou wrote: > This is with libusb-0.1-4. > > I'm trying to build a USB device. I was having problems, so I've > temporarily excised my more complex code, and am now just repeatedly > sending blocks of fixed data from it over endpoint 2, which is > configured as an interrupt IN endpoint. It has a wMaxPacketSize of 64. > > On the host, I get (via usb_interrupt_read with a 64 byte buffer) the first packet. I get the number of bytes that the device sends, whether that is 64 or something smaller like 32. > The next read times out. > This is the same whether I'm sending 64 byte packets from the device or > smaller ones. > Three important questions: what speed is the device (low, high, full), what timeout value are you specifying, and what is the interval in the endpoint descriptor? For example, if you had specified (even accidentally) a long interval and a short timeout, you would see exactly this kind of behavior. An interrupt endpoint only gets one opportunity during each of its intervals. After that, nothing gets sent until the next interval, whether you have a request timing out or not. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
From: Lou <lou...@fi...> - 2008-07-23 17:33:16
|
On Wed, Jul 23, 2008 at 09:55:02AM -0700, Tim Roberts wrote: > Lou wrote: > > This is with libusb-0.1-4. > > > > I'm trying to build a USB device. I was having problems, so I've > > temporarily excised my more complex code, and am now just repeatedly > > sending blocks of fixed data from it over endpoint 2, which is > > configured as an interrupt IN endpoint. It has a wMaxPacketSize of 64. > > > > On the host, I get (via usb_interrupt_read with a 64 byte buffer) the first packet. I get the number of bytes that the device sends, whether that is 64 or something smaller like 32. > > The next read times out. > > This is the same whether I'm sending 64 byte packets from the device or > > smaller ones. > > > > Three important questions: what speed is the device (low, high, full), > what timeout value are you specifying, and what is the interval in the > endpoint descriptor? Full speed (12Mbps). Timeout=5000ms. bInterval=10. > For example, if you had specified (even accidentally) a long interval > and a short timeout, you would see exactly this kind of behavior. Yes. > An > interrupt endpoint only gets one opportunity during each of its > intervals. After that, nothing gets sent until the next interval, > whether you have a request timing out or not. That is just an artifact of the host polling the device every bInterval ms, yes? Most of those polls will get a NAK, but the ones that don't, will fill the buffer (on the host) until it is full or until a short packet is received. If that's it, then I understand what you're saying, but I'm not sure it applies to my situation, given that my interval is much shorter than my timeout. |
From: Tim R. <ti...@pr...> - 2008-07-23 17:42:57
|
Lou wrote: > On Wed, Jul 23, 2008 at 09:55:02AM -0700, Tim Roberts wrote: > >> An interrupt endpoint only gets one opportunity during each of its >> intervals. After that, nothing gets sent until the next interval, >> whether you have a request timing out or not. >> > > That is just an artifact of the host polling the device every bInterval ms, yes? > Right. It's just easy to get confused by the interval; if you simply changed your device to high-speed, for example, the bInterval value becomes an exponent. A bInterval of 10 would mean 512 microframes (64ms), not 10 microframes. > Most of those polls will get a NAK, but the ones that don't, will fill > the buffer (on the host) until it is full or until a short packet is > received. Yes. > If that's it, then I understand what you're saying, but I'm > not sure it applies to my situation, given that my interval is much > shorter than my timeout. > Yes, I see. In that case, I'm afraid I suspect something in the device, and I don't know the device you mentioned. You may need to dig up a USB analyzer. Fortunately, full-speed analyzers are quite affordable now. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
From: Tim R. <ti...@pr...> - 2008-07-23 20:58:17
|
Lou wrote: > On Wed, Jul 23, 2008 at 10:42:56AM -0700, Tim Roberts wrote: > >> Yes, I see. In that case, I'm afraid I suspect something in the device, >> and I don't know the device you mentioned. You may need to dig up a USB >> analyzer. Fortunately, full-speed analyzers are quite affordable now. >> > > Yikes again! What constitutes affordable? Sub $100? Sub $200? The best I've > found so far is The Beagle, and that's $400. If I were doing this > professionally, I could probably justify expensive tools, but I'm not. > Yes, that's affordable. Until the Beagle was introduced, USB analyzers routinely ran many thousands of dollars, often into 5 digits. High-speed analyzers are still wicked expensive. > I think I might have found something. On the device side, as you > suggested. The line that says that the buffer is available (which is > what I'm polling) isn't going low at the end of the transfer even though > the line that says the transfer has completed goes high. Even though the > datasheet says it does. The ball is definitely in my court. > That's a good hint. The EZUSB/FX2 family has a bunch of configuration bits that define how the buffer plays like this -- whether it automatically sends on FIFO full or manually, whether it automatically fires a ZLP on a packet-sized send, etc. My guess is that you'll find the problem in that kind of thing. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
From: Lou <lou...@fi...> - 2008-07-28 20:33:42
|
On Wed, Jul 23, 2008 at 01:58:15PM -0700, Tim Roberts wrote: > Lou wrote: > > On Wed, Jul 23, 2008 at 10:42:56AM -0700, Tim Roberts wrote: > > > >> Yes, I see. In that case, I'm afraid I suspect something in the device, > > > I think I might have found something. On the device side, as you > > suggested. The line that says that the buffer is available (which is > > what I'm polling) isn't going low at the end of the transfer even though > > the line that says the transfer has completed goes high. Even though the > > datasheet says it does. The ball is definitely in my court. > > > > That's a good hint. The EZUSB/FX2 family has a bunch of configuration > bits that define how the buffer plays like this -- whether it > automatically sends on FIFO full or manually, whether it automatically > fires a ZLP on a packet-sized send, etc. My guess is that you'll find > the problem in that kind of thing. Just following up; I've found my problem. Due to a coding error in the device (which was very easy to read right past several times), I was configuring the hardware for the endpoint to be ISO IN, rather than the Bulk/Interrupt IN that all of my other code and my datasheet reading were expecting. Had I been using a constant (AT91C_UDP_EPTYPE_BULK_IN) to configure the endpoint, this would never have come up. But I thought I was building it from the endpoint descriptor's bEndpointAddress and bmAttributes whereas I was actually building it from bEndpointAddress and bDescriptorType, which is just plain wrong. After awhile, all those descriptor field names start looking the same. Everything started working when I fixed that. |
From: Lou <lou...@fi...> - 2008-07-23 20:44:32
|
On Wed, Jul 23, 2008 at 10:42:56AM -0700, Tim Roberts wrote: > Lou wrote: > > On Wed, Jul 23, 2008 at 09:55:02AM -0700, Tim Roberts wrote: > > > Right. It's just easy to get confused by the interval; if you simply > changed your device to high-speed, for example, the bInterval value > becomes an exponent. A bInterval of 10 would mean 512 microframes > (64ms), not 10 microframes. Yikes. I haven't done anything with high speed yet. I'll have to keep that landmine in mind in case I do. > Yes, I see. In that case, I'm afraid I suspect something in the device, > and I don't know the device you mentioned. You may need to dig up a USB > analyzer. Fortunately, full-speed analyzers are quite affordable now. Yikes again! What constitutes affordable? Sub $100? Sub $200? The best I've found so far is The Beagle, and that's $400. If I were doing this professionally, I could probably justify expensive tools, but I'm not. I'd hope it would be possible to get this sort of information from something like usbmon. It, however, logs at a much higher level. It doesn't show me the polling. Just the usb_interrupt_read call and return. The device I mentioned is just an ARM microcrontroller family. All of the family (with USB support) uses the same logic block to implement the USB device port. Would it be any different for you if I were using an ez-usb chip? I've used those before and can probably relearn enough to talk the talk. I help other people in online fora all the time, and I know that if you've got nothin', you've got nothin'. Thank you for looking at my problem. I've since changed the endpoint to bulk (both in the descriptor and in in my test program on the host) and get the same result. So at least that rules out anything to do with it being an interrupt endpoint. I assume there is a 1:1 correspondence between usb_bulk_read and a USB IN packet being sent to the device for packets smaller than wMaxPacketSize. I think I might have found something. On the device side, as you suggested. The line that says that the buffer is available (which is what I'm polling) isn't going low at the end of the transfer even though the line that says the transfer has completed goes high. Even though the datasheet says it does. The ball is definitely in my court. |
From: Johannes E. <joh...@er...> - 2003-12-10 01:22:28
|
On Tue, Dec 09, 2003, erbenton <erb...@co...> wrote: > I am new to the list. I browsed the archives and see references to > usb_interrupt_read. What do i have to do to call that? It isnt in any of > the files i downloaded (libusb-0.1.7.tar). I'm trying to get interrupt > data from a tripplite UPS its an omnism1000usb model. The software you > can download from their website is useless so i want to see if i can > detect the power states of the UPS which is connected via USB. I i get > it working I'll share the code of course. Also, f anyone has messed with > this unit and has learned anything I would appreciate a copy of the > info. The interrupt read support is only in the CVS version right now. You may have problems however since your UPS is a HID device and may be claimed by the HID driver on your system. What OS are you running? JE |
From: Stephen H. W. <we...@gr...> - 2003-12-10 14:06:21
|
> From: Johannes Erdfelt <joh...@er...> > Cc: lib...@li... > Content-Disposition: inline > X-Spam-Score: 0.0 (/) > X-Spam-Report: Spam Filtering performed by sourceforge.net. > See http://spamassassin.org/tag/ for more details. > Report problems to https://sf.net/tracker/?func=add&group_id=1&atid=200001 > Sender: lib...@li... > X-Original-Date: Tue, 9 Dec 2003 20:22:25 -0500 > Date: Tue, 9 Dec 2003 20:22:25 -0500 > X-Spam-Score: 0.0 (/) > X-Spam-Report: Spam Filtering performed by sourceforge.net. > See http://spamassassin.org/tag/ for more details. > Report problems to https://sf.net/tracker/?func=add&group_id=1&atid=200001 > X-UIDL: W!Ud9KH%!!&o>!!mgfd9 > X-Text-Classification: gphoto > X-POPFile-Link: http://ralph:8080/jump_to_message?view=popfile598=7.msg > > On Tue, Dec 09, 2003, erbenton <erb...@co...> wrote: > > I am new to the list. I browsed the archives and see references to > > usb_interrupt_read. What do i have to do to call that? It isnt in any of > > the files i downloaded (libusb-0.1.7.tar). I'm trying to get interrupt > > data from a tripplite UPS its an omnism1000usb model. The software you > > can download from their website is useless so i want to see if i can > > detect the power states of the UPS which is connected via USB. I i get > > it working I'll share the code of course. Also, f anyone has messed with > > this unit and has learned anything I would appreciate a copy of the > > info. > > The interrupt read support is only in the CVS version right now. > > You may have problems however since your UPS is a HID device and may be > claimed by the HID driver on your system. > > What OS are you running? For Mac OS X (Darwin), simply call usb_bulk_read on an endpoint that happens to be an interrupt endpoint. Don't know about others. -Stephen H. Westin Any information or opinions in this message are mine: they do not represent the position of Cornell University or any of its sponsors. |
From: Daniele B. <bel...@ti...> - 2003-12-10 17:33:03
|
|For Mac OS X (Darwin), simply call usb_bulk_read on an endpoint that |happens to be an interrupt endpoint. Don't know about others. about others: i've found many definitions for Linux with no code... is there any work in progress/idea ... i would like to hack in that, but i didn't receive any feedbacks on previous works/attempts. -- Daniele. "I could have made money this way, and perhaps amused myself writing code. But I knew that at the end of my career, I would look back on years of building walls to divide people, and feel I had spent my life making the world a worse place." Richard Stallman |
From: Stephen H. W. <we...@gr...> - 2003-12-10 17:45:58
|
> Date: Wed, 10 Dec 2003 18:32:47 +0100 > From: Daniele Bellucci <bel...@ti...> > Cc: lib...@li... > Content-Disposition: inline > X-UIDL: aX7e9W')e9aWB!!_Vbd9 > X-Text-Classification: personal > X-POPFile-Link: http://ralph:8080/jump_to_message?view=popfile607=1.msg > > > |For Mac OS X (Darwin), simply call usb_bulk_read on an endpoint that > |happens to be an interrupt endpoint. Don't know about others. > > about others: i've found many definitions for Linux with no code... is there > any work in progress/idea ... > i would like to hack in that, but i didn't receive any feedbacks > on previous works/attempts. Well, looking at the libgphoto2 code, that seems to be the way libusb works on all platforms. Here's the actual code from libgphoto2/libgphoto2_port/usb/libusb.c: static int gp_port_usb_check_int (GPPort *port, char *bytes, int size, int timeout) { int ret; if (!port || !port->pl->dh) return GP_ERROR_BAD_PARAMETERS; ret = usb_bulk_read(port->pl->dh, port->settings.usb.intep, bytes, size, timeout); if (ret < 0) return GP_ERROR_IO_READ; return ret; } I'm using libusb 0.1.7; I think it's the released version, at least as far as Linux is concerned. -Stephen H. Westin Any information or opinions in this message are mine: they do not represent the position of Cornell University or any of its sponsors. |
From: Daniele B. <bel...@ti...> - 2003-12-10 17:50:35
|
On Wed, Dec 10, 2003 at 12:45:51PM -0500, Stephen H. Westin wrote: |> Date: Wed, 10 Dec 2003 18:32:47 +0100 |> From: Daniele Bellucci <bel...@ti...> |> Cc: lib...@li... |> Content-Disposition: inline |> X-UIDL: aX7e9W')e9aWB!!_Vbd9 |> X-Text-Classification: personal |> X-POPFile-Link: http://ralph:8080/jump_to_message?view=popfile607=1.msg |> |> |> |For Mac OS X (Darwin), simply call usb_bulk_read on an endpoint that |> |happens to be an interrupt endpoint. Don't know about others. |> |> about others: i've found many definitions for Linux with no code... is there |> any work in progress/idea ... |> i would like to hack in that, but i didn't receive any feedbacks |> on previous works/attempts. | |Well, looking at the libgphoto2 code, that seems to be the way libusb |works on all platforms. Here's the actual code from |libgphoto2/libgphoto2_port/usb/libusb.c: whhoooppppss ... sorry for the mistake ;( i meant usb_submit_urb -- Daniele. "I could have made money this way, and perhaps amused myself writing code. But I knew that at the end of my career, I would look back on years of building walls to divide people, and feel I had spent my life making the world a worse place." Richard Stallman |
From: Johannes E. <joh...@er...> - 2003-12-10 22:02:50
|
On Wed, Dec 10, 2003, Stephen H. Westin <we...@gr...> wrote: > > Date: Wed, 10 Dec 2003 18:32:47 +0100 > > From: Daniele Bellucci <bel...@ti...> > > Cc: lib...@li... > > Content-Disposition: inline > > X-UIDL: aX7e9W')e9aWB!!_Vbd9 > > X-Text-Classification: personal > > X-POPFile-Link: http://ralph:8080/jump_to_message?view=popfile607=1.msg > > > > > > |For Mac OS X (Darwin), simply call usb_bulk_read on an endpoint that > > |happens to be an interrupt endpoint. Don't know about others. > > > > about others: i've found many definitions for Linux with no code... is there > > any work in progress/idea ... > > i would like to hack in that, but i didn't receive any feedbacks > > on previous works/attempts. > > Well, looking at the libgphoto2 code, that seems to be the way libusb > works on all platforms. Here's the actual code from > libgphoto2/libgphoto2_port/usb/libusb.c: > > static int > gp_port_usb_check_int (GPPort *port, char *bytes, int size, int timeout) > { > int ret; > > if (!port || !port->pl->dh) > return GP_ERROR_BAD_PARAMETERS; > > ret = usb_bulk_read(port->pl->dh, port->settings.usb.intep, > bytes, size, timeout); > if (ret < 0) > return GP_ERROR_IO_READ; > > return ret; > } > > I'm using libusb 0.1.7; I think it's the released version, at least as > far as Linux is concerned. It won't work on all platforms, hence the reason I started implementing usb_interrupt_read in libusb CVS. Some platforms check the endpoint you're trying to use and refuse bulk transfers to interrupt endpoints. It will work, but isn't exactly clean. JE |
From: Stephen H. W. <we...@gr...> - 2003-12-10 22:07:43
|
> From: Johannes Erdfelt <joh...@er...> > Date: Wed, 10 Dec 2003 15:07:22 -0500 > > On Wed, Dec 10, 2003, Stephen H. Westin <we...@gr...> wrote: > > > Date: Wed, 10 Dec 2003 18:32:47 +0100 > > > From: Daniele Bellucci <bel...@ti...> > > > Cc: lib...@li... > > > Content-Disposition: inline > > > X-UIDL: aX7e9W')e9aWB!!_Vbd9 > > > X-Text-Classification: personal > > > X-POPFile-Link: http://ralph:8080/jump_to_message?view=popfile607=1.msg > > > > > > > > > |For Mac OS X (Darwin), simply call usb_bulk_read on an endpoint that > > > |happens to be an interrupt endpoint. Don't know about others. > > > > > > about others: i've found many definitions for Linux with no code... is there > > > any work in progress/idea ... > > > i would like to hack in that, but i didn't receive any feedbacks > > > on previous works/attempts. > > > > Well, looking at the libgphoto2 code, that seems to be the way libusb > > works on all platforms. Here's the actual code from > > libgphoto2/libgphoto2_port/usb/libusb.c: <snip> > It won't work on all platforms, hence the reason I started implementing > usb_interrupt_read in libusb CVS. Ah, but it's OK on vanilla Linux; I've been using it in libgphoto2 on RH9 for some time now. -Stephen H. Westin Any information or opinions in this message are mine: they do not represent the position of Cornell University or any of its sponsors. |
From: Johannes E. <joh...@er...> - 2003-12-10 22:31:07
|
On Wed, Dec 10, 2003, Stephen H. Westin <we...@gr...> wrote: > > From: Johannes Erdfelt <joh...@er...> > > Date: Wed, 10 Dec 2003 15:07:22 -0500 > > > > On Wed, Dec 10, 2003, Stephen H. Westin <we...@gr...> wrote: > > > Well, looking at the libgphoto2 code, that seems to be the way libusb > > > works on all platforms. Here's the actual code from > > > libgphoto2/libgphoto2_port/usb/libusb.c: > > <snip> > > > It won't work on all platforms, hence the reason I started implementing > > usb_interrupt_read in libusb CVS. > > Ah, but it's OK on vanilla Linux; I've been using it in libgphoto2 on > RH9 for some time now. I know that, I was the one who originally suggested they do that :) However, it's not guaranteed to work for much longer and I think the behaviour may have changed for 2.6 (or atleast talked about). Regardless, it's a bad idea to rely on it. JE |
From: erbenton <erb...@co...> - 2003-12-10 16:02:53
|
On Tue, 2003-12-09 at 17:22, Johannes Erdfelt wrote: > On Tue, Dec 09, 2003, erbenton <erb...@co...> wrote: > > I am new to the list. I browsed the archives and see references to > > usb_interrupt_read. What do i have to do to call that? It isnt in any of > > the files i downloaded (libusb-0.1.7.tar). I'm trying to get interrupt > > data from a tripplite UPS its an omnism1000usb model. The software you > > can download from their website is useless so i want to see if i can > > detect the power states of the UPS which is connected via USB. I i get > > it working I'll share the code of course. Also, f anyone has messed with > > this unit and has learned anything I would appreciate a copy of the > > info. > > The interrupt read support is only in the CVS version right now. > > You may have problems however since your UPS is a HID device and may be > claimed by the HID driver on your system. > > What OS are you running? > > JE > I'm running Mandrake 9.0 on an x86 system. I dont think anything is claiming the UPS, but how can i tell? Eric |
From: Charles L. <cl...@gh...> - 2003-12-10 04:02:57
|
On Tuesday, December 9, 2003, at 07:13 PM, erbenton wrote: > I'm trying to get interrupt > data from a tripplite UPS its an omnism1000usb model. The software you > can download from their website is useless so i want to see if i can > detect the power states of the UPS which is connected via USB. As Johannes indicated, you probably have an UPS which uses the HID protocol. In that case, you may find the Network UPS Tools <http://www.exploits.org/nut/> and apcupsd projects to be of interest. Using your OS's HID API saves you from the work of re-implementing the HID protocol in your own application. -- Charles Lepple cl...@gh... |