This series implements support for BayLibre ACME device and also adds some additional configuration options for sigrok.
Changes in version 3: - switched to using glib functions for string/file manipulation where applicable, - fixed channel index assigning (previously channels had probe indecies assigned), - initialized GError instances to NULL - any other value causes GLib to emit an error message: 'GError set over the top of a previous GError or uninitialized memory' - split the driver into api and protocol parts, - several minor fixes according to code review by Uwe Hermann @Uwe: Some answers to your questions: > This looks unrelated. What's the error message or effect when this is > not present? Either way, it should probably be in an extra patch since > it's not ACME specific. Without this macro 'target_os' variable is not set (only 'host_os' is). We don't care about the host, because if we want to use ACME, then we'll be cross-compiling libsigrok for BeagleBone Black (ARM). This macro allows us to determine the target system and exclude ACME if it's not Linux. It doesn't break anything for native builds - 'host_os' is still set properly. http://airs.com/ian/configure/configure_5.html#SEC33 > The open/read here could also be done using glib functions as in the > rest of the file I guess? I switched to using glib string and file functions in most other places (probe_name_path() etc.), but this is the driver's bottleneck. We measured a significant delay when using any wrappers around open/read/close - be it fopen/fscanf/fclose or glib equivalents - probably due to userspace memory allocations. I'd prefer it to stay this way, as this driver is only compiled for Linux anyway. > SR_ERR_BUG may not be the best fit here, it's meant to show bugs of the > libsigrok backend/drivers, not so much the fact that some hardware is > not responding or accessible or such. Is it ok to just forward whatever error code has been returned by the underlying protocol.c function like I did in this version? I don't use ret = bl_acme_read_shunt_values() on purpose - if we'd ever happen to use SR_OK_CONTINUE for some reason and wouldn't want to forward it to the callback caller. > Hm, this may need a clearer name. Switching on and off certain devices > or probes or whatever is probably not specific to a "power-monitor", > correct? Note that there's already SR_CONF_POWER_OFF as well: > > /** Power off the device. */ > SR_CONF_POWER_OFF, > > Not quite the same thing, but adding the very generic > SR_CONF_POWER_SWITCH probably adds confusion here. Any ideas for > clearer naming? I did see SR_CONF_POWER_OFF, but it's not very useful in our case, as its boolean argument can't convey the information about the number of the probe on which to power-switch should be toggled. Frankly I don't have any good ideas. I changed it to SR_CONF_PROBE_POWER in this version, but it's too very generic. Version 2: https://www.mail-archive.com/sigrok-devel@lists.sourceforge.net/msg01436.html Version 1: https://www.mail-archive.com/sigrok-devel@lists.sourceforge.net/msg01432.html Bartosz Golaszewski (10): configure.ac: Add AC_CANONICAL_SYSTEM macro. baylibre-acme: Initial driver skeleton. baylibre-acme: Driver implementation. configure.ac: Compile baylibre-acme driver for Linux only. SR_CONF_SHUNT_RESISTANCE: new option SR_ERR_IO: new error code baylibre-acme: add support for shunt resistance setting SR_CONF_PROBE_POWER: new option baylibre-acme: add Linux-specific GPIO helpers baylibre-acme: add support for SR_CONF_PROBE_POWER Makefile.am | 8 + configure.ac | 11 + include/libsigrok/libsigrok.h | 19 ++ src/drivers.c | 6 + src/error.c | 2 + src/hardware/baylibre-acme/api.c | 417 ++++++++++++++++++++++++ src/hardware/baylibre-acme/gpio.c | 169 ++++++++++ src/hardware/baylibre-acme/gpio.h | 41 +++ src/hardware/baylibre-acme/protocol.c | 594 ++++++++++++++++++++++++++++++++++ src/hardware/baylibre-acme/protocol.h | 97 ++++++ src/hwdriver.c | 4 + 11 files changed, 1368 insertions(+) create mode 100644 src/hardware/baylibre-acme/api.c create mode 100644 src/hardware/baylibre-acme/gpio.c create mode 100644 src/hardware/baylibre-acme/gpio.h create mode 100644 src/hardware/baylibre-acme/protocol.c create mode 100644 src/hardware/baylibre-acme/protocol.h -- 2.1.4 ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
