project: skipper

library
this is a virtual instrument library, it does not attempt to implement any ivi standards(though it may in the future).this library is for control of (generally electronics but may support other) test equipment such as
- oscilloscopes
- PSU
- electronic loads
- multimeters
- switches
so far there is a support for
- transports
- linux TCP sockets
- linux UDP sockets
- instruments
- oscilloscopes
- keysight EDUX1052G
- electronic loads
- korad KEL102/3
- PSU
- siglent SPD3303XE
- DMM
- siglent SDM3055
- switchSet
test system
this is an exciting future development and is subject to massive change... the basic idea is to make some form of GUI test composer that is able to programmatically design and run tests on E/EE/PE assemblies and possibly others... the simplest way to describe this would be along the lines of: "given the hardware and test equipment configuration, step the input voltage and output current producing graphs of efficiency and load regulation". the ability to also define states and others will also be neededthe concept is underworked so far but given the reasonable level of drivers i am now in a position to design this
blog
the new build system has an improved test system by enabling coverage and generating gcovr reports
there is now 100% coverage unit testing of the datastructures and >90% coverage of the utils directories. the utils are lower as there seem to be some redundant checks leading to never-followed branches. the pruning of these is planned
the new interface is easier to extend and to read
the testing was fun, the switchBox was connected to a toy keyboard from argos in such a way that each individual key could be pressed and the speaker was connected to an oscilloscope. the keys were then pressed in turn with the oscilloscope measuring the signals. this measurement was verified and was within a reasonable bound(given that the keyboard has lots of jitter and drift)
here are some outputs of the power tester. they are regulation and efficiency graphs for the flyback on the switchbox project
the tool in the frontend is not desirable, it was produced to provide some insight into how best to proceed while also providing useful output(was used to verify that the switchBox PSU operated correctly(it did))
the plan is still to have a frontend that can be used to open and run tests that are stored in config files. how it will do this is still TBD...
this has all led to a fairly large change in development environment, i now have the following in emacs
- eglot (LSP)
- company-mode (autocompletion)
- have left the terminal! i use the GUI
- a nice start-of-day function that sets the frames and tabs up how i like
as this is a makefile project, it needs a clang compile_commands.json for the clang utilities to work. this is done with bear which was in the debian repos. all that is done is either: call make through bear bear -- make -j or(if there are existing build remains) make compile_commands.json
it wasnt so good at the start as clang-format(which eglot-format-buffer uses) uses the wrong formatting style. this was fairly straightforward to configure though so not too bad
clang-tidy is a big beast, it can be fooled into breaking things by telling it to fix code enough times!(im still learning lots about modern C++!) but can be reigned in like other static analysers... i settled on the following checks configuration performance*,modernize*,-modernize-use-trailing-return-type,readability*,-readability-redundant-control-flow,-readability-identifier-length,-readability-magic-numbers,-modernize-redundant-void-arg,-readability-else-after-return,-modernize-use-equals-default,-modernize-pass-by-value which seem reasonable?
all of this because i want to be able to control some instruments!
there are loads of quality improvements though
- docs
- proper compiler error flags
- unit testing
docs are simple and are being worked on, when reasonable docs will move over to being an ongoing process
compiler error flags should have been done when the Makefiles were written and there is a big chance that enabling the normal -Wall -Werror -Wextra flags will cause some nontrivial rework
unit testing will be new, ive only done a little bit of CPP unit testing and that was in TESSY which is out of my price range
when the SDM3055-SC driver with scancard support is written it will implement a new scanningDMM interface
there is now also some minimal support for gitea actions
this will lead to a new DMM and scanningDMM? interface. the interface name for when a DMM with a scan card is used is currently undecided as this may fit better under a DAQ label but this is uncertain as i have not looked at DAQ that deeply