- * - Add support for other models. Currently exclusively supports the
- * ETH008-B model which was used during implementation of the driver.
- * (Descriptions for more models were added, their operation is yet
- * to get verified.) Getting relay state involves variable length
- * responses, bits appear to be in little endian presentation.
- * - Add support for absent relay output channels (ETH484 lacks R5..R8).
- * - Add support for digital inputs. ETH484 has command 0x25 which gets
- * two bytes, the second byte carries eight digital input bits.
- * ETH1610 has 16 inputs, evaluates both bytes. Is data format u16be?
- * ETH8020 support code is inconsistent, implements two accessors
- * which either retrieve two or three bytes, while callers access the
- * fourth byte of these responses? Cannot have worked, seems untested.
- * - Add support for analog inputs. ETH484 has command 0x32 which takes
- * a channel number, and gets two bytes which carry a u16be value(?).
- * So does ETH8020. Channel count differs across models.
- * - Are there other models of interest? ETH1610 product page reads
- * as if the card had 10 relays (strict output), and 16 inputs which
- * could either be used in analog mode, or simply get interpreted as
- * digital input?
+ * - Add support for other models.
+ * - The Ethernet (and Wifi) devices should work as they are with
+ * the current implementation.
+ * https://www.robot-electronics.co.uk/files/eth484b.pdf.
+ * - USB could get added here with reasonable effort. Serial over
+ * CDC is transparently supported (lack of framing prevents the
+ * use of variable length requests or responses, but should not
+ * apply to these models anyway). The protocol radically differs
+ * from Ethernet variants:
+ * https://www.robot-electronics.co.uk/files/usb-rly16b.pdf
+ * - 0x38 get serial number, yields 8 bytes
+ * - 0x5a get software version, yields module ID 9, 1 byte version
+ * - 0x5b get relay states, yields 1 byte current state
+ * - 0x5c set relay state, takes 1 byte for all 8 relays
+ * - 0x5d get supply voltage, yields 1 byte in 0.1V steps
+ * - 0x5e set individual relay, takes 3 more bytes: relay number,
+ * hi/lo pulse time in 10ms steps
+ * - for interactive use? 'd' all relays on, 'e'..'l' relay 1..8 on,
+ * 'n' all relays off, 'o'..'v' relay 1..8 off
+ * - Modbus may or may not be a good match for this driver, or may
+ * better be kept in yet another driver? Requests and responses
+ * again differ from Ethernet and USB models, refer to traditional
+ * "coils" and have their individual and grouped access.
+ * https://www.robot-electronics.co.uk/files/mbh88.pdf
+ * - Reconsider the relation of relay channels, and digital outputs
+ * and their analog sampling and digital input interpretation. The
+ * current implementation is naive, assumes the simple DO/DI/AI
+ * groups and ignores their interaction within the firmware.