Drop unneeded log messages, add some others that might be useful,
document which ones we're intentionally not emitting.
Don't log "$operation successful" type of messages in most cases,
that's too verbose; logging failures only is sufficient there.
baylibre-acme: Don't log "No such file or directory" messages during scan,
this triggers on all kinds of unrelated devices (e.g. "AMDGPU i2c bit
bus 0x91" in this case):
sr: [...] baylibre-acme: Name for probe 1 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-0040/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 2 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-0041/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 3 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-0044/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 4 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-0045/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 5 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-0042/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 5 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-004c/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 6 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-0043/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 6 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-0049/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 7 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-0046/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 7 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-004f/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 8 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-0047/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 8 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-004b/name”: No such file or directory
The previous implementation used to provide datafeed packets which
contain logic data in positions that correspond to disabled channels.
Do mask out logic data of disabled channels in the memory image before
it is sent to the session's datafeed. This implementation works fine for
those situations where either all logic channels are enabled (default
configuration) or when only the upper channels get disabled (which can
be considered a typical use case).
For those configurations where enabled channels follow disabled channels
(i.e. setups with gaps in the sequence of enabled channels) behaviour
will be unexpected: Neither is the mask adjusted to contain gaps, nor
will enabled channels get mapped to result in a dense representation.
The respective code paths are marked with TODO comments.
Add a comment to discuss a non-obvious generator call for analog data in
the acquisition start routine, while we are here.
The generator logic determines how many samples per group (analog and
logic) need to get produced, then keeps iterating until each group has
reached the specified count. Different groups can generate different
numbers of samples per iteration, they have their own stride.
It's essential to check whether all channels in a group are disabled, to
then completely skip the respective half of the generation loop. Without
this check, the group would be expected to generate data but it won't,
which results in an endless loop. This was observed with analog channels.
There was another issue with logic channels. Unexpected logic data was
seen in the output although neither logic channel was selected.
This commit fixes bug #923.
Skip the emission of session datafeed packets for disabled analog
channels.
Implementation detail: Allow for quick lookup of the channel that is
associated with an analog generator, as the data generation routines
only pass generator references in later calls.
This fixes part of bug #923 (which initially is about unexpected
logic data while analog channels were affected in similar ways).
After the requested number of samples was sent, another session df
packet was emitted with one sample for the analog channels, which
contained the most recent result of averaging. Make this emission
depend on the "averaging requested?" flag.
This fixes bug #930.
The 'demo' driver supports scan options to adjust the number of
supported channels, and runtime control for the enabled state of
channels.
Starting with zero analog channels created (scan option) resulted in a
runtime assertion. Creating but disabling analog channels (GUI checkbox,
CLI option) resulted in unexpected output for disabled channels.
Move the creation of a hash table out of the conditional loop that
iterates over created analog channels. Which results in the table's
always being valid, and iteration during data acquisition yields no
analog output as is expected.
This fixes bug #625.
A previous implementation of the demo driver supported the creation of
larger channel counts yet only enabling part of them by default. This
was kind of pointless, I just was not aware of the available scan
options.
Drop the "enabled channels" limitation, enable all channels that get
created (like the implementation before the experiment did), and create
as many channels as was compiled in by default or later got specified
by scan options.
Bump the number of supported logic channels from 8 to 128. This is
mostly motivated to test the 64 channels limit which some of the
components/subprojects of the sigrok project might have (input/output
modules, user interfaces).
Only automatically enable the first 8 of the 128 total logic channels,
i.e. default to the previous behaviour. Prepare to only enable part of
the set of analog channels, but stick with their being active by default
as well.
Factor out the choice for the default logic pattern, too. This allows
for easier adjustment of the default configuration, when settings are
concentrated in a single spot.
Extend the demo driver, add another waveform choice for logic channels.
Create a "cable squid" logo representation which occupies a large number
of channels.
This pattern occupies 128x128 pixels. Unlike the 'sigrok' pattern it
gets repeated when more channels are involved, but is not shifted in the
repetition.
devc->step is not reset on acquistion start, so acquisition
starts with a different value every time. Thats annoying when
using the demo driver to debug sigrok, so lets make sure that
it's reset to 0.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Some of the standard helper functions take a log prefix parameter that is
used when printing messages. This log prefix is almost always identical to
the name field in the driver's sr_dev_driver struct. The only exception are
drivers which register multiple sr_dev_driver structs.
Instead of passing the log prefix as a parameter simply use the driver's
name. This simplifies the API, gives consistent behaviour between different
drivers and also makes it easier to identify where the message originates
when a driver registers sr_dev_driver structs.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
../src/hardware/appa-55ii/api.c: In function ‘scan’:
../src/hardware/appa-55ii/api.c:47:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/arachnid-labs-re-load-pro/api.c: In function ‘scan’:
../src/hardware/arachnid-labs-re-load-pro/api.c:62:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/atten-pps3xxx/api.c: In function ‘scan’:
../src/hardware/atten-pps3xxx/api.c:81:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/brymen-dmm/api.c: In function ‘scan’:
../src/hardware/brymen-dmm/api.c:89:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/cem-dt-885x/api.c: In function ‘scan’:
../src/hardware/cem-dt-885x/api.c:74:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/conrad-digi-35-cpu/api.c: In function ‘scan’:
../src/hardware/conrad-digi-35-cpu/api.c:45:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/demo/demo.c: In function ‘scan’:
../src/hardware/demo/demo.c:255:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/fluke-dmm/api.c: In function ‘fluke_scan’:
../src/hardware/fluke-dmm/api.c:64:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/gmc-mh-1x-2x/api.c: In function ‘scan_1x_2x_rs232’:
../src/hardware/gmc-mh-1x-2x/api.c:147:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/gmc-mh-1x-2x/api.c: In function ‘scan_2x_bd232’:
../src/hardware/gmc-mh-1x-2x/api.c:234:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/ikalogic-scanaplus/api.c: In function ‘scan’:
../src/hardware/ikalogic-scanaplus/api.c:69:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/tondaj-sl-814/api.c: In function ‘scan’:
../src/hardware/tondaj-sl-814/api.c:44:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
Some driver scan() functions only ever return a single device. For those it
is possible to slightly simplify the handling of the device list by
creating it on demand when the function returns.
Some drivers also have the following expression:
devices = g_slist_append(devices, sdi);
...
if (!devices)
...
This check will never evaluate to false so it is dropped as well.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
A common task during device scan is to add the newly discovered devices to
the instance list of the driver. Currently this is done by each driver on
its own. This patch introduces a new helper function std_scan_complete()
which takes care of this. The function should be called at the end of a
driver's scan() callback before returning the device list.
Doing this with a helper function provides guaranteed consistent behaviour
among drivers and hopefully paves the way to moving more standard
functionality directly into the sigrok core.
Another common task that every driver has to do for each device instance is
to initialize the device's driver field. So this is done in the new helper
function as well.
All drivers that can make use of the new helper are updated.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The sigrok core needs a list of all available drivers. Currently this list
is manually maintained by updating a global list whenever a driver is added
or removed.
Introduce a new special section that contains the list of all drivers. The
SR_REGISTER_DEV_DRIVER() and SR_REGISTER_DEV_DRIVER_LIST() macro is used to
add drivers to this new list. This is done by placing the pointers to the
driver into a special section. Since nothing else is in this section it is
known that it is simply a list of driver pointers and the core can iterate
over it as if it was an array.
The advantage of this approach is that the code necessary to add a driver
to the list is completely contained to the driver source and it is no
longer necessary to maintain a global list. If a driver is built it will
automatically appear in the list, if it is not built in won't. This means
that the list is always correct, whereas the previous approach used ifdefs
in the global driver list file which could get out-of-sync with the actual
condition when the driver was built.
Any sr_dev_driver structs that are no longer used outside the driver module
are marked as static.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Most drivers have a forward declaration to their sr_dev_driver struct at
the beginning of the driver file. This is due to historic reasons and often
no longer required. So remove all the unnecessary forward declarations.
Some drivers still require the forward declaration, but only reference the
driver struct from within the driver scan() callback. Since the driver
struct is passed to the scan callback replace the references to the global
variable with the local parameter. In some cases this requires adding the
parameter to some of the helper functions that are called from the scan()
callback.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The demo device has support for specifying the number of analog and logic
channels it should have. Currently this does not work correctly if one of
them is set to zero. Being able to set the number of channels to zero for
one of the channel types is quite useful for corner case testing though.
Make the following modifications to handle it correctly:
1) If the channel count is zero no channel group for that channel type
should be created since a channel group needs at least one channel.
2) Drop the check if logic_unitsize is less or equal to zero in
prepare_data() since this condition will always be true if the number of
logic channels is zero and it is not possible to create a demo device with
only analog channels.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Now that the signature of std_init() matches that of the driver init()
callback we can remove all wrapper functions around std_init() and use it
directly as the init() callback.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
std_init() checks if the pass in struct sr_dev_driver is non-NULL and
prints a error message and returns an error if it is NULL.
std_init() is exclusively called from driver init() callbacks for which the
core already checks if the struct sr_dev_driver is non-NULL before invoking
the callback. This means the check in std_init() will always evaluate to
false. So drop this check.
This also means that the prefix parameter that was used in the error
message is no longer needed and can be removed from the function signature.
Doing so will make the std_init() function signature identical to the
init() callback signature which will allow to directly use it as such.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The std_init() callback has the order of the first two paramters opposite
to the init() callback. This is primarily due to historical development.
Since the std_init() function is usually called from a driver's init()
callback aligning the order will allow direct register pass through rather
than having to swap them around. It also allow to eventually use the
std_init() function directly as the init() callback.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
SR_CONF_CONTINUOUS is a capability option indicating whether a device
supports continuous capture or not. If the option exists the device
supports continuous capture and otherwise it doesn't. There is no value
associated with it and hence setting the SR_CONF_SET flag is nonsensical.
None of the drivers which set SR_CONF_SET for SR_CONF_CONTINUOUS handle it
in their config_set() callback and return an error if an application tried
to perform a config_set() operation for SR_CONF_CONTINUOUS.
Simply remove the SR_CONF_SET flag from all SR_CONF_CONTINUOUS options.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Every single hardware driver has the very same implementation of the
dev_list() callback. Put this into a helper function in the standard helper
library and use it throughout the drivers. This reduces boiler-plate code
by quite a bit.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
std_init() allocates a drv_context struct which needs to be freed by the
driver in its cleanup struct. But the vast majority of drivers does never
does this causing memory leaks.
Instead of addressing the issue by manually adding code to free the struct
to each driver introduce a new helper function std_cleanup() that takes
care of this. In addition to freeing the drv_context struct std_cleanup()
also invokes sr_dev_clear() which takes care of freeing all devices
attached to the driver.
Combining both operations in the same helper function allows to use
std_cleanup() as the cleanup callback for all existing drivers, which
reduces the amount of boiler-plate code quite a bit.
All drivers are updated to use the new helper function.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Devices for the demo driver do have additional data attached to it that
needs to be freed when the device is freed. While the driver gets it right
for the cleanup() callback it does not implement a dev_clear() callback, so
the default dev_clear() implementation is used which will not free the
additional data. This will cause memory leaks when sr_dev_clear() is called
for this driver.
To fix this provide a dev_clear() implementation that frees the additional
data.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
This makes the code shorter, simpler and more consistent, and also
ensures that the (same) debug messages are always emitted and the
packet.payload field is consistently set to NULL always, etc.
Timer intervals shorter than about 100 ms are unnecessarily taxing
on system resources. Also, on systems like Windows the smallest
resolvable time unit without using high precision timers is about
15 ms. Regular timer intervals should be well above that value to
avoid being dominated by noise and round-off.
Since Autoconf places some important feature flags only into the
configuration header, it is necessary to include it globally to
guarantee a consistent build.
Uwe Hermann
Gerhard Sittig
Soeren Apel
Sven Schnelle
Aurelien Jacobs
Lars-Peter Clausen
Daniel Elstner