new HP-IL software implementation in C++20

[brouhaha]

Thanks! This might eventually be useful as a reference, but it won't be suitable to run on small microcontroolers as the memory footprint is fairly large. Part of that might be due to use of some STL containers, which I don't really need. However, in general I think HP's app note on HP-IL device design is a better guide for designing non-controller devices that use a 1LB3 (or later equivalents).

I worked very hard to get the configuration to be generated statically, using C++ templates with constexpr, etc., so that the compiler can leave out all code paths not needed. For instance, a very basic non-controller device would have its configuration statically generated at compile time from an HP-IL capabilities string and a few more parameters. In the following example, an HP-IL interface configuration is created for a "Fidget" electronic instrument that supports talk, receive, service request, extended (secondary) addressing, remote-local, parallel clear, and device trigger.

Code:


constexpr hpil::Configuration fidget_config =
    hpil::configure<"T1,2,3,4,6 L1,3 SR1 RL2 AA2 PP1 DC2 DT1",  // HP-IL interface capabilities
                    "Fidget",   // device ID
                    "\x55">();  // accessory ID: instrument, signal source & measurement

Since the configuration is "constexpr" (which required quite a bit of template trickery under the hood), the HP-IL capabilities string is parsed at compile time, and the structure is static (ROMable). Each HP-IL interface function has a bitfield in the hpil::Configuration, so in this example, fidget_config.c[0], fidget_config.t[3], and fidget_config.sr[1] are true, but fidget_config.c[1], fidget_config.t[5], fidget_config.l[2], and fidget_config.dd[1] are false.

The HP-IL "interface" is then instantiated using that configuration. Here is an example of creating a fidget interface:

Code:


hpil::Interface<fidget_config> fidget1("fidget1");

The configuration is used as a template parameter, which means that the HP-IL interface code will be compiled for exactly the configuration needed, with none of the code needed to support capabilities that aren't used. In this example, the C (controller), PD1 (power down command), and DD1 (device dependent talker/listener) code will be omitted, as will many of the state transition tests and actions.

Note that there could potentially be mroe than one HP-IL interface of type "fidget" in the same program, or HP-IL interfaces of different configurations.

I certainly understand some aspects of HP-IL much better than I did previously.

Once I've debugged it enough that it might be worthwhile, I'll put it on github, and post a link here.