On Mar 14, 2018, at 7:26 AM, Berge, Matthijs ten wrote:
>
> Can anyone point me in the right direction where I should start? I already
> found http://networkupstools.org/docs/developer-guide.chunked/ar01s04.html,
> but it doesn't give any specific tips for serial communication. For example,
> which source can I use best as a starting point?
> Or does anyone recognize this protocol, and is it already compatible with an
> existing driver?
>
Those strings don't show up in a quick search of the driver source code, so it
looks like you are correct in that you will need to write a new driver.
A little further down on the page you cited is the list of serial functions
provided by NUT (Section 4.11). There are also a few contrived serial examples
in drivers/skel.c, which we recommend copying as a starting point for a driver.
This is all assuming that your OS recognizes the FTDI chip as a USB-to-serial
converter, and creates the appropriate character device (for instance,
/dev/ttyUSB* on Linux). There are other USB drivers in NUT that communicate
with non-kernel-supported USB-to-serial converters, but there are complications
with wrestling the USB interface away from the kernel driver, so I'd advise
against that if you can help it.
I don't recall any other drivers which parse a continuous stream of data
without sending a query command. For a query/response example, ivtscd.c is
relatively straightforward to understand.
Given the fixed-length strings and unambiguity of the commands, you might want
a loop like the following:
ser_flush_in()
while(!done && !timed_out) {
ser_get_char()
// append to buffer
check for match
check for timeout
}
One thing that may be useful while waiting for hardware is to embed a test
harness in the code. We don't have much of a standard for this, but as long as
the code doesn't turn into spaghetti, feel free to use something like "#ifdef
TESTING" to allow the driver to be tested offline.
If you do need to do systems-level testing before the driver is complete, you
may be interested in the dummy-ups driver. It allows you to write a script of
the data you expect the SITOP driver to return, and then test system shutdown
or notifications. Obviously, this requires making a number of assumptions about
the UPS, but it is a starting point if you want to allow some parallel
development.
http://new.networkupstools.org/docs/man/dummy-ups.html or if the build
infrastructure is being cranky,
http://networkupstools.org/docs/man/dummy-ups.html
Please use reply-all to include the list when responding - this list does not
mangle the headers.
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
