Charles, thanks for your comprehensive answer. It has definitely pointed me in 
the right direction. With the skeleton driver and the example ivtscd.c I can 
probably figure it out now.

After testing is done, you'll see the PR (I hope) ;-)

Matthijs

-----Original Message-----
From: Charles Lepple [mailto:clep...@gmail.com]
Sent: woensdag 14 maart 2018 13:35
To: Berge, Matthijs ten <m.tenbe...@awl.nl>
Cc: nut-upsuser@lists.alioth.debian.org
Subject: Re: [Nut-upsuser] Interfacing with Siemens SITOP UPS500S

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.
DISCLAIMER: For our full disclaimer, please visit 
www.awl.nl/en/about-us/disclaimer

_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Reply via email to