[Nut-upsdev] Re: [Nut-upsuser] Ablerex 625L USB version
Peter Selinger
selinger at mathstat.dal.ca
Thu Feb 1 22:03:02 CET 2007
I think perhaps 2) and 3) can be implemented in a single driver. In
any case, each subdriver has its own method for sending and receiving.
They are not uniform even across category 2).
-- Peter
Carlos Rodrigues wrote:
>
> On 2/1/07, Jon Gough <jon.gough at eclipsesystems.com.au> wrote:
> >
> > Carlos,
> > 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.
> >
> > However, I cannot pass 'data' to the UPS as I am issuing numeric
> > commands, ie:
> >
> > if (strcmp(str, "Q1\r" [image: Winking smiley] == 0)
> > {
> > upsdebugx(4, "set_data_ablerex: Doing Q1 stuff" [image: Winking
> > smiley];
> > rc = usb_get_string_simple(udev, 3, report_buf, sizeof(report_buf));
> > get_done = TRUE;
> > }
> >
> > I would like to find out how to pass the longer commands with variable
> > parameter data to the UPS.
> >
>
>
> Ok, I see.
>
> Then the current status is...
>
> We now have three variants for megatec transport:
>
> 1) megatec over RS-232
> 2) megatec over USB in a simple send/receive string fashion
> 3) megatec mapped to USB specific stuff
>
> 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) "
> megatec-transport-ablerec.c"
>
> 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.
>
>
> > Anyway. I think you should go to bed! 4am is for sleeping not coding! Here
> in Australia it is only 15:10, (or 04:10
> > UTC, which of course you already know!).
>
>
> I'm something of a night creature. But with work and studying for pending
> exams a 24 hour day is just too short. :)
>
>
> --
> Carlos Rodrigues
>
> ------=_Part_10727_7609186.1170343710623
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> On 2/1/07, <b class="gmail_sendername">Jon Gough</b> <<a href="mailto:jon.gough at eclipsesystems.com.au">jon.gough at eclipsesystems.com.au</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
>
> <div>
> <font size="3">Carlos,<br>
> 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.<br><br>
> However, I cannot pass 'data' to the UPS as I am issuing
> numeric commands, ie:<br><br>
> if (strcmp(str, "Q1\r&quot
> <img alt="Winking smiley" height="19" width="19"> == 0)<br>
> {<br>
> upsdebugx(4, "set_data_ablerex: Doing
> Q1 stuff&quot
> <img alt="Winking smiley" height="19" width="19">;<br>
> rc = usb_get_string_simple(udev, 3,
> report_buf, sizeof(report_buf));<br>
> get_done = TRUE;<br>
> }<br><br>
> I would like to find out how to pass the longer commands with variable
> parameter data to the UPS.</font></div></blockquote><div><br><br>Ok, I see.<br><br>Then the current status is...<br><br>We now have three variants for megatec transport:<br><br> 1) megatec over RS-232<br> 2) megatec over USB in a simple send/receive string fashion
> <br> 3) megatec mapped to USB specific stuff<br></div><br>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.
> <br><br>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.
> <br><br>Then 1) would be "serial.c", 2) "megatec-transport-usb.c", 3) "megatec-transport-ablerec.c"<br><br>But don't worry about that just now. It is more important to see it working, this refactoring can be done later.
> <br><br>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.<br><br><br></div><font size="3">> Anyway. I think you should go to bed! 4am is for sleeping not coding!
> Here in Australia it is only 15:10, (or 04:10<br>> UTC, which of course you
> already know!).<br></font><br><br>I'm something of a night creature. But with work and studying for pending exams a 24 hour day is just too short. :)<br><br><br>-- <br>Carlos Rodrigues
>
> ------=_Part_10727_7609186.1170343710623--
>
>
> --===============9154910438181402239==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
> --===============9154910438181402239==--
>
More information about the Nut-upsdev
mailing list