[Nut-upsdev] megatec over USB - using Andrey Lelikov's approach

[Charles Lepple]

On 12/31/06, Alexander I. Gordeev <lasaine at lvk.cs.msu.su> wrote:
> On Sun, 31 Dec 2006 17:29:37 +0300, Arjen de Korte <arjen at de-korte.org> wrote:
>
> > I would prefer to name this serial_usb.o, since it is basically a serial
> > protocol over an USB interface.
>
> Ok.
>
> > Indeed and furthermore, we might be able to make this generic enough
> > that other drivers (with similar hardware) can use it too.
>
> Well, I think it's already done by Andrey. Here is his own comment from
> megatec_usb.c:
> /*
>       This is a communication driver for "USB HID" UPS-es which use proprietary
> usb-to-serial converter and speak megatec protocol. Usually these are cheap
> models and usb-to-serial converter is a huge oem hack - HID tables are bogus,
> device has no UPS reports, etc.
>       This driver has a table of all known devices which has pointers to device-
> specific communication functions (namely send a string to UPS and read a string
>   from it). Driver takes care of detection, opening a usb device, string
> formatting etc. So in order to add support for another usb-to-serial device one
> only needs to implement device-specific get/set functions and add an entry into
> KnownDevices table.
>
> */
> And IMHO his driver has no megatec-specific code and could be even more
> generic after quite few modifications.

I guess I didn't look carefully enough - the routines are separated out.

> On Sun, 31 Dec 2006 17:37:43 +0300, Charles Lepple <clepple at gmail.com> wrote:
>
> > It would probably be best to leave the file with a
> > manufacturer-specific name until someone actually gets around to
> > merging all of the serial-over-USB routines.

I take this back - the megatec_usb.c file is more flexible than what I
thought when I quickly glanced at it. The nut_usb.c file has a number
of assumptions about the mappings of send/receive to the different USB
transfer types. If we change the bcmxcp_usb driver to use the
megatec_usb.c style, then we will be closer to seeing generic userland
USB-to-serial converter support.

I would agree with Arjen, though, that it is useful to have the
USB-specific routines have the same calling conventions as serial.c.

> > We already have a nut_usb.c which contains Powerware-specific
> > functions, but I don't think that's a good precedent.
> >
> > Not to be too pessimistic, but if there are not enough spare UPSes (of
> > a given brand) that can be used for testing, then making the routines
> > more generic probably won't happen any time soon. I am all in favor of
> > the concept, though.
>
> Do you mean megatec or krauler (actual UPS brand)?
> And please look at what I wrote above in reply to Arjen.
> Sorry for receiving this message twice.

I guess I meant "protocol" instead of "brand". Alexander, you said you
have a spare UPS, but in order to make these routines generic, other
drivers that are part of the merge would need to be tested against the
new code.

There's a good chance that the tripplite_usb and tripplite drivers
could be consolidated this way as well, since it appears that they use
similar commands (judging by code alone). We would need someone to go
back to the older serial-only driver and see what it returns as its
"protocol ID" (if any), though, and I don't know how many people have
access to old Tripp Lite serial UPSes that we could test
pre-beta-quality code against.

-- 
- Charles Lepple