[Nut-upsdev] Driver for Powerware 3105 (USB)

[Charles Lepple]

On 8/18/05, Wolfgang Ocker <weo at weo1.de> wrote:

> Is there any interest in that driver?

It's always hard to judge the interest in the driver beforehand. But
the code looks nice, and as far as I'm concerned, it sounds worthwhile
to integrate it into NUT.

What version of NUT is this based off of? (release version number, or
CVS branch)

Arnaud: if you're too busy, do you want me to look at merging this
driver into the tree?

> Should I combine the serial and
> the USB driver? Perhaps it makes sense to have separate binaries because
> of library dependencies. But besides the command IO functions the
> drivers are identical.

You have a good point about separate binaries. Maybe what you could do
is divide bcmxp.c and bcmxp_usb.c into three files: generic Powerware
command support, Powerware-specific serial code, and
Powerware-specific USB code. (The nut_usb.c is already a step in the
right direction, IMHO. As other drivers pop up, some of that code can
be parameterized - timeouts, number of retries, etc.)

This way, you can still have separate binaries, and if people don't
want to install libusb, they don't have to (and they will only get
serial interfaces, like with the existing USB drivers). But if there
are any bugfixes to the core powerware code, you don't have to apply
them to both bcmxp.c and bcmxp_usb.c.

It's up to you to decide whether it is worth it, though, since you
have the USB units to test with. It would also be good to get the
bcmxp.c authors to buy into this idea. Maybe the driver code is small
enough to maintain two separate drivers.

I have to say, though... Powerware chose a really strange method of
passing in commands (SET_DESCRIPTOR/DT_STRING).

> Since I'm new to USB programming I'm not sure whether the error handling
> and reconnect processing is correct. I'd appreciate any comments and
> suggestions.

Given the variablilty in USB devices and host controllers, I'd say go
with whatever works.

-- 
- Charles Lepple