Handle I/O sources and timer ("dummy") sources within the same
polling loop, so that both may be used together. Slightly change
the API to improve consistency: a timeout value of -1 now disables
the timeout, and 0 makes the source always time out immediately.
The "dummy" sources already behaved that way, although it wasn't
documented as such.
Make sure that I/O events are processed preferentially: Skip any
timeout callbacks if an I/O event occurred within the same poll
iteration. This applies to both timer/idle sources and timeouts
of I/O sources.
Do not create dummy GPollFDs for timer/idle sources. Instead,
split the sources array into an I/O section and a timer section,
and create corresponding GPollFDs only for the I/O section. Use
GArray to simplify the handling of the dynamic arrays.
Keep track of when source timeouts are due and properly compare
against accumulated elapsed time between invocations. This prevents
sources with short timeouts from blocking other sources with longer
timeouts indefinitely.
This requires sr_hw_cleanup_all() and sanity_check_all_drivers()
to also take a context.
The (runtime) generation of the driver list now happens in sr_init()
and sr_driver_list() always returns that pre-generated list. This fixes
a segfault when (correctly) invoking multiple sr_init() and sr_exit()
calls with different contexts (caught by the unit tests).
This fixes bug #565.
This is a partial fix for bug #343, which lead to a large amount of
handles being created, and eventually to a frontend "hang".
It's not yet a "full" fix as some issues are still observable,
but it successfully improves the situation on Windows to the extent
that frontend hangs due to large amounts of handles no longer seem
to happen.
Thanks to Boris Gjenero <boris.gjenero@gmail.com> for the debugging
efforts, testing, and updating of this patch!
Additionally, this seems to also fix a "SysClk LWLA hanging" bug
and apparently not receiving any samples during an acquisition
(tested on an LWLA1034).
This closes bug #328.
It fills the fields with reasonable default values that should suit
most of the drivers. Drivers are obviously free to override the fields
they want after initializing.
Add a protocol decoder for the Cyrustek ES51919 LCR meter chip.
This chipset (together with ES51920 front-end) is supposedly used
by multiple different portable LCR meters including at least
DER EE DE-5000, Yihua V&A VA520, Mastech MS5308, Uni-T UT612,
CEM DT-9935 and various OEM rebadges of them.
The communication protocol seems to be implemented on the Cyrustek
chip itself so all the different models are expected to use the
same protocol if they implement a host connection. Unfortunately
the protocol is not available in the public documentation of the
chipset, so this implementation is based on reverse engineering it
from traffic captures.
The actual connection between the meter and the host computer may be
different from meter to meter even when based on the same chip. This
module implements a decoder for the protocol and some common helper
functions for interfacing with the meter via an RS-232 serial port.
This calculates a proper timeout value for blocking writes on the
given serial port, for the given number of bytes. Timeout is based
on a fixed 10ms OS overhead, baud rate, data bits and stop bits.
Set this new parameter to 0 (no timeout) at every call site. This is
consistent with previous behaviour, so cannot cause any regressions.
Waiting forever for a serial operation is clearly always wrong. Without
specific knowledge of each device and driver however, I can't choose
appropriate timeouts for each call. The maintainers of these drivers
will need to do so, and also add appropriate handling of timeouts.
When this commit is merged, a bug should be entered for each driver
that is touched by it.
This signifies to the module instance no more input will come. This
will cause the module to process any data it may have buffered. The
SR_DF_END packet will also typically be sent at this time.
When an input module instance has received enough input to fully
populate the struct sr_dev_inst, sdi_ready is set to TRUE and its
receive() method returns immediately. Any remaining received data
is buffered until the next time the function is called.
There is currently no way to uniquely identify USB devices in
libsigrok. It uses the "bus.address" scheme which is only
constant as long as the device remains attached to the bus.
In order to allow USB device persistence in PulseView, devices
need to provide a unique identifier even in absence of a
serial number. This function is the first step as it provides
the ability to query the physical location of a USB device.
Daniel Elstner
Uwe Hermann
Bert Vermeulen
Soeren Apel
Aurelien Jacobs
Martin Ling
Joel Holdsworth
Uffe Jakobsen
Janne Huttunen