Hi! Here's my WIP version of a driver for my DER EE DE-5000 LCR meter. It works and exports all the main functionality the device has, but of course the actual implementation may still require some cleaning up or e.g. better handling of some corner cases. I do welcome any comments on both the design and implementation of this work (or anything else too for that matter). As this is the first LCR meter to actually be supported by sigrok, it will act as a reference and thus should preferably export the "correct" APIs now.
The protocol between the host PC and the device is based on my own reverse engineering from traffic dumps. As far as I know there is no public document that describes it (feel free to point me into it if you know better). It appears that once again the protocol essentially just sends to the host the same information that is currently visible on the display of the device. Especially in the case of an LCR meter I tnink this is a bit of a shame. I think it would make much more sense to send some raw or lightly pre-processed measurements (like e.g. the complex Z) to the host and do all the math in there. That would allow the functionality to be extended while now the host can only act as a dumb data logger. But, it is what it is and at least I don't know any way to change that in this particular meter, so this driver is modeled to just export whatever the protocol contains. I ended up exporting the used measurement model as a set of new quantities instead of flags because I realized that I would have required two of them and while the flags are very much a finite resource, the MQs are almost infinite. I still ended up using three flags even without the model flags. Two fo them are for reporting different auto-selections the same way the current auto-ranging flag does and the last one is for implementing the a bit unorthodox relative mode the meter has. The test signal frequency was exported as a new config key. I was not quite sure whether to use integer or float for the value, but ultimately ended up using integer for it. It does not support fractions of a hertz, but on the other hand it won't get any rounding errors either. In a way something like 'double' would probably have the "best of both worlds", but there seems to be very little precedent for using it in sigrok and on the other hand I don't know if fractions of a hertz are ever useful in the context of ouput frequency(?). During my research I also found out that the meter is based on a common LCR meter chipset, so I separated the chipset code into it's own module. This made the driver itself only a very thin shim. All the "heavy lifting" is done by the chipset specific module that can be shared if any of the other LCR meters based on the same chipset ever get supported in sigrok. During the course of the implementation I also found myself wishing that there were more generic helper functions available for the drivers. Currently the amount of copy-pasted "boilerplate" the driver needs is quite staggering compared to size of the actual parser code. Yes, I know now that there is some way to generate a "template" for a driver, but I realized that only after I had already too far in the implementation (I guess real men(tm) don't read documentation, my bad) and even with then I think the common parts of the drivers could be generalized in helpers. I have now written some for my ow driver, but at least some of them could be useful if named properly, polished and put into some common file so that other drivers could use them too. Feel free to suggest any such routines in this driver (with desired name, API and destination file, if possible). One thing that I would also like to ask about is the sr_dev_driver struct. Is it exported for some purpose or should it actually be split into exported and private parts? Currently any changes in there are potentially an API/ABI breakage, which seems unnecessary to me, but maybe it actually is so by design(?). I would like to have at least one change in the driver operations, but it is not so easy to do if the functions are considered to be a part of the stable API/ABI. So, comment away! Janne Huttunen (9): Add two new units. Add measured quantities for LCR meters. Add quantity and flag for difference measurements. Add two new 'auto' flags. Add config key for LCR meter type. Add config key for output frequency. Add pretty-printer for new units and flags. Add protocol decoder for Cyrustek ES51919 LCR meter chip. Add driver for DER EE DE-5000 LCR meter. Makefile.am | 8 + configure.ac | 9 +- include/libsigrok/libsigrok.h | 36 ++ src/drivers.c | 6 + src/hardware/deree-de5000/api.c | 92 ++++ src/lcr/es51919.c | 917 ++++++++++++++++++++++++++++++++++++++++ src/libsigrok-internal.h | 20 + src/output/analog.c | 13 + 8 files changed, 1098 insertions(+), 3 deletions(-) create mode 100644 src/hardware/deree-de5000/api.c create mode 100644 src/lcr/es51919.c -- 2.1.1 ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://p.sf.net/sfu/Zoho _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
