There are three commands: one to write the default config, one to write
the embedded udev rules file, and one to actually run the program.
I might reformat the help text at some point. It's not very nice as-is.
There's not really any analogous concept for azimuth. This is for a
specific piece of hardware, so there's no real point in making it more
generic. This is respected at the 180 degree point as well, for
software that can handle flipped rotation configurations.
This doesn't currently play well with the elevation offset setting,
which should be applied after this clamping operation. Either this
needs to be moved to the API layer or (more appropriately) the input
range validation needs to move in the controller.
This is missing a little bit of input validation, e.g. we don't
currently check that set_position azimuth and elevation are actually
in the range that the controller can possibly move.
The geodetic north offset configuration value is applied in when
computing the current position, but I think there are still some
slightly fiddly edge cases around it and I haven't actually figured
out which direction I want the sign to be.
The various pieces appear to be functional, so next up will be figuring
out what all the problems are with some hardware in the loop.
I will probably spend more time on this than I plan to, though I am not
really writing this to run on Windows. At this point, Windows
compilation works but when the driver attempts to read the HID
descriptor, the response is only 45 bytes instead of the expected 75
(which is what it gets when run on Linux). I was under the impression
that this response was just raw data from the device itself, but it's
clearly handled differently on the different platforms, so I think it
will be somewhat interesting to dig into what is different between the
two and why. It's possible I may actually learn something along the
way, unfortunately.
The only pthread functionality this seems to use is mutexes, which are
(fortunately) theoretically trivial to wrap for windows. This
compiles, though it is not clear if it actually works correctly.
The Labjack API provided by ljacklm is, quite frankly, dog doodoo. I
say this as disrespectfully as possible. A lot of the API calls take
specific (implictly sized) arrays that must be 0-filled just so the
API can loop over them and fill them with a different number.
Everything parameter is either long or a float (and I think the use of
long is a carryover from the insane Win32 ABI where long is a 32 bit
integer rather than 64 bit, which it is on most Posix platforms). The
functions have a tendency to do 15 different things in a single call,
and most of the function parameters are out parameters or even better,
inout parameters. Some functions take arrays where other ones require
the user to manually bitpack an integer.
I've got the source for it right here and could rewrite it, but I don't
hate myself enough to do that. The API surface I need is minimal, so
I've just wrapped the parts I will be using. Ideally I will not need
to touch this again, but it does still need to be tested with actual
hardware, so we're not out of the woods yet.
