[Nut-upsdev] Re: [Nut-upsuser] Ablerex 625L USB version
jon.gough at eclipsesystems.com.au
Fri Feb 2 01:45:04 CET 2007
I have just done a test with your code and it does work.
I was doing my work on the latest stuff from SVN to see if that
would help in my investigations. I did not apply the patches from
previous mails, just used the code in the later modules (the patch
process produced errors).
It does not matter which version we use as both work for me, now.
We just need to implement a few more commands into your code, if we
use that, and work out how to implement the code that sends data to
the UPS, ie the S<n>, S<n>R<m> and T<n> commands. I also want to
implement the TL, C and CT commands, but I whilst I can see the
reaction to these it is a little difficult to work out the code to use.
I think the F command may need a little more work as I think it
may need to issue the '0x01' command first to get the manufacturer.
Anyway, both sets of code work, for me at least, so it is up to
the powers that be to decide which way to go.
Output from upsc command with your code
At 09:36 2/02/2007, Alexander I. Gordeev wrote:
>I've tried to explain what I have achieved but I see that you haven't
>got it. Let's try again.
>(Sorry, if all this is because of my bad English, I'm not a native
> > Here is a level 4 dump of the output I currently get. This
> > shows that apart from the first call which is to the comm_usb_recv
> > without calling the comm_usb_send first, most of it is working. The
> > functions I have not implemented end up doing what the original code
> > did, ie set_report, get_interrupt.
> > I am using Serial-Over-USB to drive my UPS. I have taken the
> > work that was done for the AGILER interface and added the ABLEREX
> > interface. However, I could not get the 'get_interrupt' command to
> > work. It would not return any useful data. So I had to change the
> > 'set_data code' to issue 'usb_get_string_simple' and translate the
> > character requests into index numbers. The 'get_data' just reads a
> > static variable that is set by the 'set_data'. In this way I can get
> > most of the functionality working.
>1. I've asked you to test the patch I supplied without any change,
> > Our devices seem to be mostly identical!
>That means that only one _subdriver_ is needed. So the functions
>get_data_krauler/set_data_krauler are ready to work with your UPS too.
>I see no point in writing this subdriver once again, as you did. They
>are just quite similar, really.
>2. Also I don't get why have you prefered 2 month old patch,
>which won't compile against current trunc, as the base for your work.
>I've reworked it, as I wrote about a week ago. What I did:
> - renamed all the functions like in serial.c. So now you don't need
> to change megatec.c in any way. If you don't understand why I did it,
> please refer to the discussion that took place in December.
> - fixed some bugs from the original patch. And, I believe, didn't
> introduced new ones. I've checked everything hard. However, not all
> the bugs (that original code has) are fixed yes. There are at least 2
> of them yet. I'll work on them.
> - wrote a new subdriver to support my own UPS. Again, I'm sure, it
> _will_ support somehow your device. I thought that you could figure
> it out.
>One thing I haven't done: UPS commands. I had to stop adding features
>after I met the bug I've already written about yesterday:
> > ...
> > Trying to match device
> > Device matches
> > HID descriptor, method 1: (9 bytes) => 09 21 00 01 00 01 22 70 02
> > HID descriptor, method 2: (9 bytes) => 09 21 00 01 00 01 22 70 02
> > HID descriptor retrieved (Reportlen = 624)
> > Unable to get Report descriptor (-88): Invalid or incomplete
> multibyte or wide character
> > No appropriate HID device found
>I guess, this bug is specific to my UPS. But I don't know it for sure
>:( So, please, test my code without changes and send all output to me.
>It will be really great.
>Of course, I'll test your code too. Maybe, it will stop the bug...
>I'm looking forward for the patch.
>Please, tell me if you have any questions...
> > The idea is to keep megatec unmodified, and up until now a simple
> > USB communications layer with the same API as the serial layer would
> > make this possible. The only catch was the need to add "subdrivers"
> > to support different models, but otherwise this layer could even
> > prove useful for protocols other than megatec.
> > The original agiler interface by Andrey Lelikov modifies
> > "megatec.c" to add that USB layer, but I think it should be just an
> > outside file with the same API as the serial layer, and linked at
> > compile time to generate an ablerex specific driver, even if it
> is megatec specific.
> > Then 1) would be "serial.c", 2) "megatec-transport-usb.c", 3)
> > But don't worry about that just now. It is more important to see it
> > working, this refactoring can be done later.
> > When I have some free time I'll check which one of these transport
> > mechanisms my own UPS uses. Then I'll be able to help in refactoring
> > whatever code we have by that time.
>Well, I've done this refactoring.
>Sorry, if you've received this message twice!
> Alexander mailto:lasaine at lvk.cs.msu.su
>Nut-upsdev mailing list
>Nut-upsdev at lists.alioth.debian.org
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 000709-2, 01/02/2007
Tested on: 2/02/2007 11:45:09 AM
avast! is copyright (c) 2000-2007 ALWIL Software.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nut-upsdev