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.
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.
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.
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.
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.
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.
This call is executed from an event handler context was previously
nonblocking, however there is no handling for a partial write.
The output buffer is unlikely to be full and the commands to be sent
are short, so it should be OK to make this a blocking call.
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.
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.
Scan options do not have capabilities bits.
Martin Ling
Soeren Apel
Bert Vermeulen
Uwe Hermann