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:

while(!done && !timed_out) {
    // 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 

http://new.networkupstools.org/docs/man/dummy-ups.html or if the build 
infrastructure is being cranky,

Please use reply-all to include the list when responding - this list does not 
mangle the headers.
Nut-upsuser mailing list

Reply via email to