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.
fx2lafw: Use physical USB connection instead of sdi->index
Previously, sdi->index was used to tell several identical fx2lafw-compatible
devices apart. This was a bit of a hack, so this patch makes it use physical
device connections instead. They're guaranteed to remain the same even if
the USB device reconnects.
Martin Ling [Sun, 21 Sep 2014 18:24:33 +0000 (19:24 +0100)]
tondaj-sl-814: Mark serial read/write calls as blocking.
These calls are executed from an event handler and were previously nonblocking,
but they have no partial read/write handling. The code is already marked TODO
for improvement.
Martin Ling [Sun, 21 Sep 2014 18:14:05 +0000 (19:14 +0100)]
norma-dmm: Make serial write call block.
This call is executed from an event handler and was previously nonblocking,
but has no partial write handling. It sends a short packet so should be OK
to block, most likely the output buffer will be empty anyway.
Martin Ling [Sun, 21 Sep 2014 18:11:23 +0000 (19:11 +0100)]
norma-dmm: Mark serial read call as nonblocking.
This call was already nonblocking since the driver opens the port with the
SERIAL_NONBLOCK flag. It only reads one byte, and a zero result is handled
appropriately.
Martin Ling [Sun, 21 Sep 2014 18:03:26 +0000 (19:03 +0100)]
motech-lps-30x: Make serial write call block.
This call was previously explicitly nonblocking, but has no partial write
handling. It sends a short packet so should be OK to block, most likely the
output buffer will be empty anyway.
Martin Ling [Sun, 21 Sep 2014 17:59:45 +0000 (18:59 +0100)]
motech-lps-30x: Mark serial read call as nonblocking.
This call was already nonblocking since the driver opens the port with the
SERIAL_NONBLOCK flag. It only reads one byte, and a zero result is handled
appropriately.
Martin Ling [Sun, 21 Sep 2014 17:54:00 +0000 (18:54 +0100)]
mic-985xx: Make serial write call block.
This call is executed from an event handler and was previously nonblocking,
but has no partial write handling. It sends a short packet so should be OK
to block, most likely the output buffer will be empty anyway.
Martin Ling [Sun, 21 Sep 2014 17:44:20 +0000 (18:44 +0100)]
gmc-mh-1x-2x: Make serial write calls block.
These calls are executed from an event handler and were previously nonblocking,
but have no partial write handling. They send short packets so should be OK to
block, most likely the output buffer will be empty anyway.
Fix error handling for some: serial_write can return any negative error code.
Martin Ling [Sun, 21 Sep 2014 17:36:00 +0000 (18:36 +0100)]
gmc-mh-1x-2x: Mark serial read calls as nonblocking.
These calls were already nonblocking since the driver opens the port with the
SERIAL_NONBLOCK flag. They only read one byte. A return value of zero is not
handled, but should not occur in theory due to the G_IO_IN check. It might be
good to add handling of a zero return anyway, since I'm not sure if this is
always accurate.
Martin Ling [Sun, 21 Sep 2014 17:33:34 +0000 (18:33 +0100)]
gmc-mh-1x-2x: Mark serial read call as nonblocking.
This call was already nonblocking since the driver opens the port with the
SERIAL_NONBLOCK flag. It only reads one byte, and a zero result is handled
appropriately.
Martin Ling [Sun, 21 Sep 2014 17:26:16 +0000 (18:26 +0100)]
fluke-dmm: Make serial write calls block, and fix error handling.
These calls are executed from an event handler and were previously nonblocking,
but have no partial write handling. They send short packets so should be OK to
block, most likely the output buffer will be empty anyway.
Also fix error handling for these calls, which seems to have been retained from
previous direct usage of write() to a serial port fd.
Martin Ling [Sun, 21 Sep 2014 17:16:04 +0000 (18:16 +0100)]
fluke-dmm: Make serial write calls block, and fix error handling.
These calls were previously nonblocking, but have no partial write handling.
They are made from scan and acquisition_start contexts where they are free
to block.
Remove the SERIAL_NONBLOCK at open, which only applied during scan, since all
calls in the scan are now explicitly blocking.
Also fix error handling for these calls, which appears to have been kept
from a previous direct usage of write() on a serial port fd.
Martin Ling [Sun, 21 Sep 2014 17:12:48 +0000 (18:12 +0100)]
fluke-dmm: Mark serial read call as nonblocking.
This call was already nonblocking since the driver opens the port with the
SERIAL_NONBLOCK flag. Only one byte is read. The case of 0 being returned
is not handled, but the call is only made if G_IO_IN occurred so in theory,
there should be a byte available. It might be wise to add handling for a
return of 0 nonetheless, as I'm not sure if this is always accurate.
Martin Ling [Sun, 21 Sep 2014 16:54:18 +0000 (17:54 +0100)]
colead-slm: Mark serial read calls as nonblocking.
This is an odd one. These calls are made from a receive handler so should not
block, and appear to be setup correctly to handle partial reads or no data
available. However, the driver was not opening the port with SERIAL_NONBLOCK
so these calls would have been blocking. Make them nonblocking.
Martin Ling [Sun, 21 Sep 2014 16:51:25 +0000 (17:51 +0100)]
center-3xx: Make serial write call block.
This call is executed from an event handler and was previously nonblocking,
but has no partial write handling. It sends a short packet so should be OK
to block, most likely the output buffer will be empty anyway.
Martin Ling [Sun, 21 Sep 2014 16:41:05 +0000 (17:41 +0100)]
cem-dt-885x: Mark serial access as nonblocking, remove SERIAL_NONBLOCK flag.
These calls were already nonblocking since this driver opened the port with
the SERIAL_NONBLOCK flag. Having marked them as such, we can remove the flag.
Also remove an unnecessary reopen of the port to change its blocking status.
Martin Ling [Tue, 16 Sep 2014 01:47:28 +0000 (02:47 +0100)]
brymen-dmm: Make serial write call block.
This call is executed from an event handler and was previously nonblocking,
but has no partial write handling. It sends a short packet so should be OK
to block, most likely the output buffer will be empty anyway.
Martin Ling [Tue, 16 Sep 2014 01:36:42 +0000 (02:36 +0100)]
atten-pps3xxx: Make serial write call block.
This call is executed from an event handler and was previously nonblocking,
but has no partial write handling. It sends a short packet so should be OK
to block, most likely the output buffer will be empty anyway.
Martin Ling [Tue, 16 Sep 2014 01:32:37 +0000 (02:32 +0100)]
atten-pps3xxx: Make serial write call block in scan.
This is called at scan time so free to block. There is no partial write
handling and a response is expected afterwards. This should therefore be a
blocking call.
Martin Ling [Tue, 16 Sep 2014 01:11:05 +0000 (02:11 +0100)]
agilent-dmm: Make serial write call block in scan.
This call is executed at scan time so is free to block. There is no
handling for a partial write and a response is expected immediately
afterwards. It should therefore be a blocking call.
Martin Ling [Sun, 21 Sep 2014 20:26:36 +0000 (21:26 +0100)]
serial_stream_detect: Make read nonblocking.
This code implements its own waiting based on baudrate, so the read itself
should be nonblocking. In general it will have been already, since drivers
almost universally use the SERIAL_NONBLOCK flag.
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.
Every driver now publishes its device option config keys, i.e. the
list fetched with sr_config_list(SR_CONF_DEVICE_OPTIONS), with a
set of flags indicating which methods are implemented by the driver
for that key.
The config keys are OR'ed with any combination of SR_CONF_GET,
SR_CONF_SET and SR_CONF_LIST. These are defined as the high bits
of the uint32_t config key. Clients can OR config keys with
SR_CONF_MASK to strip out these bits. This mask will be kept up to
date if other bits are added to the capabilities list; clients MUST
therefore use SR_CONF_MASK for this.
Some keys don't have capability bits added, such as the informative
device type keys (SR_CONF_MULTIMETER, SR_CONF_OSCILLOSCOPE, ...) and
SR_CONF_CONTINUOUS.
Uwe Hermann [Mon, 8 Sep 2014 21:09:05 +0000 (23:09 +0200)]
configure.ac: Don't duplicate driver name.
The AC_DEFINEs don't need any driver names really, those only end up
as code comments in config.h and are otherwise useless. Thus, don't
duplicate them, we already have the driver names in DRIVER().