there has, for several days now, been a Qt frontend which provides a PSU testing tool

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...

and its in, the PCB has been ordered from aisler. a nice surprise was the several euros discount from wurth! now to wait until december for delivery and to also order the components

even more quality improvements! (still no unit testing) the quality checks have expanded to also use clang-tidy

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!

woop! SDM3055 support is now here!

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

ive decided. the SDM3055 will first gain a SDM3055 driver which does not use the scancard. this will implement a new DMM interface

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