Set samplelimit to a sane value (was causing PulseView to
crash earlier), as well as advertise samplerate using SR_CONF_LIST
so that PulseView can show the sample rates.
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
The function drains off all the remaining data in the receive socket
and is triggered before starting a capture and after a capture is
completed. In the absence of this function, there is a possibility of
data corruption and also the NodeJS TCP server throws an error if the
buffer is not completely read out before the socket is closed.
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
BeagleLogic now supports two modes of interface - one being the
native mode running on an ARM system like the BeagleBone Black
and the other mode acting like a TCP client for the BeagleLogic
server running off a BeagleBone compatible system. This makes it
convenient for desktop users to retrieve samples from BeagleLogic,
no more copying files and SSHing into the BeagleBone hardware in
order to use BeagleLogic.
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
Organize driver functions into an ops structure (there will be
separate structures for both native and TCP mode of operation).
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
If a channel in the higher-than-8-bit group is enabled then use
16-bit captures. Otherwise just do 8-bit captures.
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
Starting with Linux kernel version 4.9, BeagleLogic attributes
setting does not require root permissions.
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
This is unlike the previous behavior to return 8 channels and then
use logic_channels to get all the 14 channels
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
Move the check for the capture ratio being 0..100 into the wrappers,
drop unneeded helper functions, fix incorrect variable types, minor
other consistency fixes.
This ensures consistent handling of the SR_CONF_SCAN_OPTIONS and
SR_CONF_DEVICE_OPTIONS (with sdi NULL or non-NULL) config keys
and also reduces copy-pasted boilerplate in the drivers a bit.
This function does not handle channel-group specific items, that's
very driver-specific and thus left to the individual drivers.
Also move some generic checks and error messages from the drivers into
the sr_config_list() wrapper.
Be explicit and consistent in the drivers about which dev_clear function
will be called to avoid confusion and inconsistencies.
Drop some open-coded implementations of std_dev_clear().
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>
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>
Some drivers set the device instance list to NULL in their scan() callback.
This means the driver loses all references to any devices contained in that
list and their resources will be leaked. Drivers can't free the devices at
this point either since an application might still use a device on the
list. So the existing devices on the instance list need to remain
unmodified during the scan() callback, even if that means that there will
be duplicates on the instance list. Only an explicit invocation of
sr_dev_clear() by the application is allowed to free the devices on the
instance list and reset the list.
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>
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>
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>
If a driver does not implement a dev_clear() callback the core will
automatically call std_dev_clear(di, NULL). Remove all driver dev_clear()
implementations that are identical to default. This reduces the amount of
boiler-plate code.
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>
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.
Trying to configure an invalid capture ratio would reset the
previously configured value. Instead, we should just reject the
new value and keep the original one.
Since Autoconf places some important feature flags only into the
configuration header, it is necessary to include it globally to
guarantee a consistent build.