My application speaks to 8 different RS232 instruments and I'm not sure if I'm going too far in saying that's common functionality.
I've been thinking of having a VISA parent class to define holding the settings, configuring the port, closing the port, some kind of error reaction.
Next child down (Simple VISA) having a 'write' and 'read' for the instruments that I only need single command write and read response control of. This is the abstract class I'd put through my test VIs and swap simple read/write instruments into.
Some of the others need to be able to have more granular control, so would inherit directly from VISA parent and define their own specific functions. (write x, write y, read z) rather than having singular 'write' and 'read' methods.
Is this sane? Examples for HALs I've seen set the abstract class at the type of instrument (power supply, multimeter etc) rather than as broad as the type of comms. Wondering if I'm looking at commonality that's unnecessary?
Something like this diagram (apologies for jankiness)
...Especially if I then wanted to also have the HAL, which would have me adding that lowest layer where I do then sperate by instrument type. Perhaps this is where my straw man of starting as high as the comms type falls down? It feels smelly but I can't place why and I have a lot of applications like this so I'd like to pin down whether this isn't good.