Hi Oliver and Stuart,
2012/2/13 Arnaud Quette <[email protected]>:
> 2012/2/7 Oliver Kluge <[email protected]>:
>> Hi Arnaud,
>
> Hi Oliver,
>
>> if you got tons of material including several protocol revisions, maybe a
>> broader approach might useful?
>
> this is to be expected from me.
>
>> I don't want to talk you into rewriting all this code, but I see space for
>> some improvement and let my imagination run wild :-) Nut drivers make a
>> difference between Fortresses and "newer Fortresses" without really drawing
>> a sharp line.
>
> that's the aim.
>
>> Are those different protocols fundamentally different? I mean, is a division
>> of different Fortress models into two separate nut drivers actually
>> indicated? Is there a revolutionary change instead of evolution?
>
> I don't see a revolution, but indeed an evolution.
>
>> If not, what about joining the two? If yes, could the division line which
>> model needs which driver be made more visible? Or could the driver instruct
>> the user to it's counterpart if the user chose the wrong one?
>>
>> Wow, all these changes must have meant tons of work for the engineers of
>> those days, bearing in mind that a UPS with such capabilities needed a PCB
>> full of circuits. And indeed the Fortress has a really large PCB compared to
>> contemporary models. And in those days there were no firmware updates.
>> Firmware was forever and essentially had to be bugfree (maybe we should
>> re-vitalize that old paradigm :-) I'm not sure if I saw even an EPROM in
>> there, maybe the code is inside the processor...
>>
>> At the time when this thing was built, if somebody would have told that a
>> time would come where I would update the firmware of my phone, my VCR and my
>> TV every couple of months :-)
>>
>> And at the time you had to support a bunch of operating systems, there were
>> unix versions, Windows, an OS/2 version. I'm quite amazed that the Checkups
>> Windows driver even runs on 7 and Vista, even 64 bit...
>
> good ol' engineering!
>
>> Sorry, I just got a little side-tracked :-)
>
> no problem, it's always good for health ;-)
>
>
> I've just started studying these docs, so no news yet...
I'm slowly progressing on that topic.
So far, the only thing I've seen are:
- the 50 ms delay should be 75 ms
- XON/XOFF are indeed to be enabled.
A patch is attached.
To apply it, from within the toplevel NUT source directory, use:
$ patch -p0 < /path/to/bestfortress-1.diff
Could you please apply it, recompile and report back as previously?
cheers,
Arnaud
--
Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
Index: drivers/bestfortress.c
===================================================================
--- drivers/bestfortress.c (révision 3446)
+++ drivers/bestfortress.c (copie de travail)
@@ -23,7 +23,8 @@
#include "main.h"
#include "serial.h"
-#define UPSDELAY 50000 /* 50 ms delay required for reliable operation */
+#define UPSDELAY 75000 /* 75 ms delay required for reliable operation */
+ /* 50 ms is the standard, but 75 ms is advised */
#define SER_WAIT_SEC 2 /* allow 2.0 sec for ser_get calls */
#define SER_WAIT_USEC 0
#define ENDCHAR '\r'
@@ -34,14 +35,15 @@
#endif
#define DRIVER_NAME "Best Fortress UPS driver"
-#define DRIVER_VERSION "0.04"
+#define DRIVER_VERSION "0.05"
/* driver description structure */
upsdrv_info_t upsdrv_info = {
DRIVER_NAME,
DRIVER_VERSION,
"Holger Dietze <[email protected]>\n"
- "Stuart D. Gathman <[email protected]>\n",
+ "Stuart D. Gathman <[email protected]>\n"
+ "Arnaud Quette <[email protected]>",
DRV_EXPERIMENTAL,
{ NULL }
};
@@ -419,6 +421,35 @@
{NULL, B1200},
};
+
+/* Code derived from serial.c, bestups.c, bestferrups.c */
+static void setup_serial(int fd, const char *port, speed_t speed)
+{
+ struct termios tio;
+
+ if (tcgetattr(fd, &tio) == -1)
+ fatal_with_errno(EXIT_FAILURE, "tcgetattr(%s)", port);
+
+ tio.c_iflag = IXON | IXOFF;
+ tio.c_oflag = 0;
+ tio.c_cflag = (CS8 | CREAD | HUPCL | CLOCAL);
+ tio.c_lflag = 0; /* in particular, ICANON is off ! */
+ tio.c_cc[VMIN] = 1;
+ tio.c_cc[VTIME] = 0;
+
+#ifdef HAVE_CFSETISPEED
+ cfsetispeed(&tio, speed); /* baud change here */
+ cfsetospeed(&tio, speed);
+#else
+#error This system lacks cfsetispeed() and has no other means to set the speed
+#endif
+
+ tcflush(fd, TCIFLUSH);
+
+ if (tcsetattr(fd, TCSANOW, &tio) == -1)
+ fatal_with_errno(EXIT_FAILURE, "tcsetattr");
+}
+
void upsdrv_initups(void)
{
speed_t speed = B1200;
@@ -438,7 +469,7 @@
}
upsfd = ser_open(device_path);
- ser_set_speed(upsfd, device_path, speed);
+ setup_serial(upsfd, device_path, speed);
/* TODO: probe ups type */
/* the upsh handlers can't be done here, as they get initialized
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
