it is done! the first PCB is built and can operate its switches

the power supply was also successful and had only one(two?) issue(s) which was that the input protection FET gates were not sufficiently protected and i had to fit the two nonpop zeners
the PSU regulates properly over the input range for 110% of the output current range(design=2A, test=2.2A) and is stable for more than 24hrs to within ten millivolts.
the efficiency isnt great, generally being in the upper 70%s but the measurement setup wasnt brilliant, the measured current values from the PSU have not been verified for correctness and may have a large amount of variance, if memory serves there is at least a 2% inaccuracy(was able to measure ~102% efficiency when the tester was in self-verification setup). the graph was also suspiciously spiky
i can finally claim victory over the LT8304!

the USB and ethernet(and therefore also clocking) have been verified before any firmware was flashed as the MCU has a vendor bootloader which may use USB or ethernet; the USB connection showed in dmesg and the ethernet BOOTP requests were visible in wireshark
the trigger subsystem was verified before fitment of the MCU or other comms interfaces and performed as required. later the exported power was loaded and the assembly thermals were reasonable

some firmware work has been done with a functional TCP connection and a couple of commands implemented. the relays have been tested using some temporary commands and perform as expected

so, early signs are good but there are still many unknowns, namely:-

• USB and ethernet at the same time
• full command set
• the chassis connectors are big and will need to be in a 4*8 arrangement, this needs to be drawn and made
• the upper PCBA is still TODO

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