rdtech-dps: rephrase how model specific ranges are handled Commit 02a4f485de76 implemented ranges support such that _all_ models including every RD as well as DPS device announced ranges, it's just that most of them happen to support a single range. Use this fact, accept any zero based index, and drop the "normalization" to strict 0/1 values except for one RD specific code path when getting the current state of multi-range supporting devices. Tell models with "effectively no ranges" from devices which "support multile ranges". This shall increase robustness and improve maintainability. Simplifies future extensions when more ranges are involved.
rdtech-dps: address simple style issues Coding style nits: Use const data for model lists. Prefer size types. Link sdi and devc immediately after allocation. Skip unused wire fields by reading them too, avoid breaking the reviewer's flow. Cosmetics, readability: Do place trailing commas in initializers. Reduce text line length. Break long lines in more appropriate locations that are more readable. Eliminate unmotivated pre-increment operators.
rdtech-dps: undo undesired register re-read logic change Commit 02a4f485de76 snuck in a change that should not have gone there. Revert the logic which re-reads Modbus registers several times before declaring failure. Use the previous implementation as intended.
rdtech-dps: add support for RD6006P, RD6012P and RD6024 RD6012P has two current ranges, so support for getting/setting/listing range is added. This also means that the model table is reorganized to support multiple ranges. In order for the range setting and the current multiplier to be up to date, the function rdtech_dps_update_range is called when required. This function reads the range register of the device.
rdtech-dps: research to reduce serial comm transfer volume again The DPS devices default to a rather low UART communication bitrate. The generous retrieval of more Modbus registers than strictly necessary for the periodic acquisition of analog channel values and state tracking may or may not be an issue. Instrument all call sites in api.c to the device state gathering calls such that the protocol.c side transparently can reduce the transfer volume depending on which level of detail the caller may expect given its current context. Under optimal circumstances this might cut the traffic in half, which DPS devices may benefit from. This commit adds the infrastructure to potentially reduce transfer volume, but does not change behaviour. The "config" reasons may need further partitioning if Modbus register access really turns out to be a severe bottleneck. The API lends itself to that extension easily. The approach which gets prepared in this commit needs to get runtime tested by those who got access to the hardware.
rdtech-dps: introduce support for RD6006 and other Riden RD models The RD devices differ from DPS devices in their default communication bitrate (115200), register content endianess (BE), and register set layout (addresses for registers). In either case 16bit registers get accessed by means of Modbus communication over a serial channel. The interpretation of the registers' values mostly is the same as for DPS devices once a register with the same meaning got identified. Device identification includes a 32bit serial number which DPS devices appear to not provide. All other product features are the same, and map to identical sigrok mechanisms. That's why re-using the rdtech-dps driver to add rdtech-rd support is considered desirable. This implementation shares all code "above" the raw register addressing and raw value interpretation. All logical processing, configuration interface, state tracking and data submission to the session feed, are shared among the different device types. Declare support for the RD6006, RD6012, and RD6018 models. Their specs were taken from the 2020.12.2 instruction manual. The driver was tested with an RD6006 device (firmware version 1.28). Unfortunately automatic device detection is not possible or will not be reliable, which is why users need to specify the respective model by picking one of the two drivers. Within a driver variant the device identification and use of the device are automatically dealt with.
rdtech-dps: layer separation between API and protocol, style nits The existing power supply driver for Riden DPS/DPH devices unfortunately duplicated intimate details of modbus communication and register layout including interpretation of raw register values across several source files. Do separate the physical transport and the register layout and register fields interpretation layers. This brings the driver in line with the usual api.c and protocol.c arrangement of responsibilities, and prepares the future addition of other similar devices. Address a few style nits while we are here. Include <config.h> in all source files, and alpha-sort include directives. Address minor data type nits. Reduce indentation in code paths. Propagate more error codes. Update comments which lagged behind the code, adjust grammer (eliminate "actual" false friends). Eliminate a few magic numbers and redundancies, switch to the more recent endianess aware byte stream reader API where beneficial, to eliminate redundant offset math. Other nits seem to have gone unnoticed before: The indices of all sigrok channels were identical (all zero). Signed print formats were used for unsigned data. This implementation compiles, but wasn't runtime tested due to lack of hardware. A rough estimate of transfer volume and transport throughput suggests that the 10ms cycle time no longer can be kept, may end up around 25ms (40 cycles per second). This can get avoided by adding more code to tell the configuration requests, the acquisition start, and the measurements grabbing during acquisition apart. It's assumed though that the 10ms glib poll interval did not translate to such fast measurement gathering. The firmware may typically provide data at lower rates anyway. The generic source code may look overly complicated or redundant at first glance, but compilers' generated code will greatly get optimized. Simplified maintenance because of reduced cognitive load is considered more important.
rdtech-dps: Retry sr_modbus_read_holding_registers() up to 3 times. The communication with the rdtech power supplies is not very reliable, especially during the start. Because of that, the driver tries to read the modbus registers up to three times. Nevertheless there is the chance, that the communication fails.