Extend the scan code path, accept user provided conn= specs in the
"vid.pid" format. Everything else is assumed to be a hidapi compatible
"path" and may suffer from conn= parser limitations. Unfortunately the
hidapi API won't let us lookup paths from bus.addr specs which would
work when multiple cards need to be told apart.
Rework the scan and probe routines. Skip the USB enumeration's result
set when the user provided a conn= spec, instead exclusively open the
specified device. It's acceptable when this user spec does not match
the details which the hidapi enumeration would yield. [ This version
prepares but does not implement yet support for "funny" hidapi(3) paths
on platforms beyond Linux. ]
This also weakens the logic which determines the relay count from the
USB product string. Any trailing number is accepted. Which allows to use
compatible devices with differing vendor/product strings when conn= is
specified. The previous "USBRelay" prefix check remains in place for
automatic enumeration.
Beautify diagnostics, even phrase debug and spew level messages such
that they can be presented to users. Makes -l 5 look more consistent.
Move all of the sdi creation into the probe routine which communicates
to the relay card. Extend diagnostics in that code path. Which leaves
pure USB enumeration in the scan routine.
Store the USB relay card's serial number such that users can tell apart
multiple connected cards. Hold the HIDAPI path in the 'connection_id'
member because 'conn' is something internal, not for display purposes.
Add the USB identification of the dcttech.com USBRelay<n> card. Which
happens to be shared with other V-USB based firmware projects. Thus is
rather generic. The USB relay card is just the first supported device
of that kind.
Implement support for the "www.dcttech.com USBRelay<n>" card. This V-USB
based HID device communicates HID reports to control up to 8 relays. The
driver depends on the HIDAPI external dependency for maximum portability.
Support for the conn= parameters is limited. A path that HIDAPI can open
is expected, which depends on the platform and HIDAPI implementation,
and may not always be expressed by means of sigrok command line options.
See README.devices for a discussion.
The USB serial number is not considered. This is an implementation
detail of the relay card's firmware. HID reports carry a five character
identifier for the board.
Relay state is cached in the driver. It's assumed that relay state won't
change outside of libsigrok control as long as the device is opened. The
single request to activate/deactivate all relays at once is supported.
The measured quantity flags for the measurement mode can only contain one flag
at maximum. Therefore the quantity flags handling can be simplified, which also
fixes a bug when switching from 4-wire resistance measurement to 2-wire mode.
The HP 3478A device would not reliably identify by means of SCPI queries. The
previous scan() implementation would have matched any connected SCPI device,
then upset these devices by emitting non-SCPI requests.
Tighten the scope of the hp-3478a probe, only scan for devices when a conn=
spec was provided. This avoids false positives and malfunction of other
devices, and still lets users address the problematic device. This is similar
to serial-dmm and unspecific cables and has proven to work there.
Undo the #include statement order change of commit 7414fb55cb. It's
essential on MacOS to include vxi.h early to keep related u_long et al
data types available. See commit d40b8557a9 for a discussion.
Also drop the inclusion of rpc/rpc.h from scpi_vxi.c because it is not
used in that source file, instead is a vxi.h dependency and is included
there.
[ gsi: rephrase commit message ]
The 'sdi' parameter to config API calls can be NULL. Only dereference
after checking its validity.
Reported-By: Alexandre Ferreira <alexandref75@hotmail.com>
Routine scpi_vxi_read_data() invokes device_read_1(), which provides a
static buffer where dynamically allocated memory for SCPI response data
is kept. Release this memory after getting a copy of the response data,
before the next device_read_1() call loses the reference.
Valgrind stats without the fix:
==238825== LEAK SUMMARY:
==238825== definitely lost: 45,547,737 bytes in 18,331 blocks
==238825== indirectly lost: 0 bytes in 0 blocks
==238825== possibly lost: 48,154 bytes in 14 blocks
==238825== still reachable: 42,859 bytes in 288 blocks
==238825== suppressed: 0 bytes in 0 blocks
Valgrind stats with the fix:
==239413== LEAK SUMMARY:
==239413== definitely lost: 40 bytes in 2 blocks
==239413== indirectly lost: 0 bytes in 0 blocks
==239413== possibly lost: 0 bytes in 0 blocks
==239413== still reachable: 38,613 bytes in 287 blocks
==239413== suppressed: 0 bytes in 0 blocks
Remaining leaks in scpi_vxi_open() are of lesser severity because they
don't accumulate during execution.
[ gsi: rebase to recent master, reword commit message ]
Address style nits to improve readablity and future maintenance.
Move system header includes before application level includes. Move
assignments out of variable declaration blocks. Separate function calls
and assignments from error checks and flow control. Break a long line.
Add braces around conditional multi line statements.
All these adjustments are cosmetical. Behaviour does not change.
With Keysight 34465A the VOLT:AC and FREQ functions keep suffering from
USB timeouts and pipe errors. Add a 10ms delay between initiating the
acquisition and checking for completion before fetching the result.
The weird thing is that when successful responses are seen after
temporary failure, enlarging the delay does not make them go away.
Instead the USB errors keep moving to a different spot. Measurements do
arrive though, so this is just annyoing but not a blocker.
sr: [00:00.134038] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
sr: [00:00.136043] scpi: Got response: '"FREQ +3.00000000E+00,+3.00000000E-06"', length 38.
sr: [00:00.136119] scpi-dmm: dev_acquisition_start: Precision: '"FREQ +3.00000000E+00,+3.00000000E-06"'
sr: [00:00.136251] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
sr: [00:00.184211] scpi: Got response: '1', length 1.
sr: [00:00.184481] scpi_usbtmc: Successfully sent SCPI command: 'INIT'.
sr: [00:00.234800] session: bus: Received SR_DF_HEADER packet.
cli: Received SR_DF_HEADER.
sr: [00:00.245597] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
sr: [00:01.246050] scpi_usbtmc: USBTMC bulk in transfer error: LIBUSB_ERROR_TIMEOUT.
sr: [00:01.256495] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
sr: [00:01.291871] scpi_usbtmc: USBTMC invalid bulk in header.
sr: [00:01.302392] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
sr: [00:01.401959] scpi: Got response: '1', length 1.
sr: [00:01.402135] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
sr: [00:01.403392] scpi: Got response: '1', length 1.
sr: [00:01.403566] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
sr: [00:01.405769] scpi: Got response: '"FREQ +3.00000000E+00,+3.00000000E-06"', length 38.
sr: [00:01.406020] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
sr: [00:01.407500] scpi: Got response: '1', length 1.
sr: [00:01.407674] scpi_usbtmc: Successfully sent SCPI command: 'FETCH?'.
sr: [00:01.409107] scpi: Got response: '+9.00555531E+01', length 15.
Experimentation suggests that 200ms timeouts reduce the probability of
these USB communication errors. But if functions tend to respond that
differently, are delay time specs per MQ required? The implementation of
the driver currently assumes a single delay spec.
Some models are slow to start a measurement acquisition in specific MQs
(meter functions). An "*OPC?" query went unanswered after "INIT" was
sent. This was observed on 34405A in temperature, frequency, resistance,
AC voltage and current mode.
Add an optional per-model measurement delay that is used when the MQ
specifies that the delay is applicable. Because functions are changed
rarely but measurements are taken many times, only the first reading
is delayed while later readings are seen at the expected interval. Not
delaying the first reading will result in device errors.
sr: [00:00.875162] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
sr: [00:00.881666] scpi: Got response: '"FREQ +1.00000E+00,+1.00000E-05"', length 32.
sr: [00:00.881700] scpi-dmm: dev_acquisition_start: Precision: '"FREQ +1.00000E+00,+1.00000E-05"'
sr: [00:00.881840] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
sr: [00:00.883966] scpi: Got response: '1', length 1.
sr: [00:00.884139] scpi_usbtmc: Successfully sent SCPI command: 'INIT'.
sr: [00:01.884420] session: bus: Received SR_DF_HEADER packet.
cli: Received SR_DF_HEADER.
sr: [00:01.895260] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
sr: [00:02.895766] scpi_usbtmc: USBTMC bulk in transfer error: LIBUSB_ERROR_TIMEOUT.
sr: [00:02.906302] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
sr: [00:02.910703] scpi_usbtmc: USBTMC invalid bulk in header.
sr: [00:02.921244] scpi_usbtmc: USBTMC bulk out transfer error: LIBUSB_ERROR_PIPE.
sr: [00:02.931802] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
sr: [00:02.932276] scpi: Got response: '1', length 1.
sr: [00:02.932425] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
sr: [00:02.934790] scpi: Got response: '1', length 1.
sr: [00:02.935155] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
sr: [00:02.941564] scpi: Got response: '"FREQ +1.00000E+00,+1.00000E-05"', length 32.
sr: [00:00.173408] hwdriver: scpi-dmm: Starting acquisition.
sr: [00:00.173569] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
sr: [00:00.334312] scpi: Got response: '1', length 1.
sr: [00:00.334544] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
sr: [00:00.341070] scpi: Got response: '"RES +1.00000E+02,+1.00000E-03"', length 31.
sr: [00:00.341307] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
sr: [00:00.343636] scpi: Got response: '1', length 1.
sr: [00:00.343872] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
sr: [00:00.350093] scpi: Got response: '"RES +1.00000E+02,+1.00000E-03"', length 31.
sr: [00:00.350157] scpi-dmm: dev_acquisition_start: Precision: '"RES +1.00000E+02,+1.00000E-03"'
sr: [00:00.350342] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
sr: [00:00.352524] scpi: Got response: '1', length 1.
sr: [00:00.352832] scpi_usbtmc: Successfully sent SCPI command: 'INIT'.
sr: [00:00.352901] session: bus: Received SR_DF_HEADER packet.
cli: Received SR_DF_HEADER.
sr: [00:00.363675] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
sr: [00:01.364363] scpi_usbtmc: USBTMC bulk in transfer error: LIBUSB_ERROR_TIMEOUT.
sr: [00:01.374904] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
sr: [00:02.375380] scpi_usbtmc: USBTMC bulk in transfer error: LIBUSB_ERROR_TIMEOUT.
sr: [00:02.385872] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
sr: [00:03.232457] scpi_usbtmc: USBTMC invalid bulk in header.
sr: [00:03.243003] scpi_usbtmc: USBTMC bulk out transfer error: LIBUSB_ERROR_PIPE.
sr: [00:03.253464] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
sr: [00:03.256568] scpi: Got response: '1', length 1.
sr: [00:03.256902] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
sr: [00:03.259440] scpi: Got response: '1', length 1.
sr: [00:03.259713] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
sr: [00:03.266070] scpi: Got response: '"RES +1.00000E+08,+1.00000E+3"', length 30.
sr: [00:03.266456] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
sr: [00:03.268501] scpi: Got response: '1', length 1.
sr: [00:03.268961] scpi_usbtmc: Successfully sent SCPI command: 'READ?'.
sr: [00:03.353589] scpi: Got response: '+9.90000000E+37 ', length 16.
Declare a 2500ms measurement initiation delay for 34405A which was found
by experimentation. This is huge but was found to be necessary.
Of course all other meter functions are unaffected by this commit. As
are the meters which specify no delay.
Some models are slow to switch meter functions to specific MQs. This was
observed with 34405A and AC V/I modes, where USB connections timed out
and suffered from pipe errors.
Add an optional delay after "CONF:<mode> [<range>]" SCPI requests. The
duration of the delay is per model, the use of the delay is per MQ on
that model. The 200ms delay for 34405A was found by experimentation.
Speaking about 34405A: Only the "INIT" request in temperature mode
remains as an issue, which is not covered by this commit's approach.
Don't use the "[SENS:]<mode>:RANGE..." request on Agilent protocol
speaking devices. Use "CONF:<mode> [<range>]" instead. This was tested
with all devices which reference this model.
In theory there is the question whether previously configured ranges
should be re-used when (exclusively) the MQ is switched. It's assumed
that this is not useful, instead users or their applications should
select the function first and optionally pick the range then. Re-use of
e.g. 10k resistance range when switching to capacitance might be seen as
confusing (and results in errors in the device).
Use the combination of INIT and FETCH? to get measurements. The READ?
request is more complex and might "undo" what INIT already initiated.
This improves perception of the 34405A meter's operation.
Rephrase the SCPI read timeouts in scpi-dmm model declarations. Shuffle
the order of product terms such that the milliseconds "unit" goes last,
and the milliseconds value goes first. Assume that "2500 * 1000 [us]"
better reflects the intention than "1000 * 2500" does.
The Fluke 45 driver's ECHO_TEST broke other people's SCPI device
identification and was disabled in 2018-11. Remove the dead code which
is impossible to resurrect. Its purpose was questionable to begin with.
Should users be affected, then the echo would break the identification
phase. The check cannot be done before identification without affecting
other connected devices, cannot be done after the identification either
when that very identification systematically fails. Should a user meet
this condition then applications' logs are available to see why *IDN?
fails, assuming that users are not aware of their serial port or device
configuration. The request's reflection in the place of a response gives
a strong hint.
Only scan for hp-3457a devices when the user specified which connection
to use. This avoids breaking SCPI devices by emitting non-standard
requests before reliable device identification.
Only scan for hpib-pps devices when a user provided conn= specification
was given. This avoids breaking SCPI devices by emitting non-standard
requests before reliable device identification.
Improve readability and simplify maintenance of the sr_scpi_scan()
routine.
Move initial assignment and subsequent update of variables in closer
proximity, don't hide assignments in declaration blocks. Use common
helper code where available. Split complex conditions into individual
terms which are easier to review and reason about. Don't mix calls and
value checks and flow control in the same statement.
Device or model or protocol variant specific commands should only be
used after the device reliably got identified. The "CHDR OFF" command
upsets other devices and needs to move after *IDN? and model checks.
The HP 59306A device was made in 1973 and would not reliably identify
by means of SCPI queries. The previous scan() implementation would have
matched any connected SCPI device, then upset these devices by emitting
non-SCPI requests.
Tighten the scope of the hp-59306a probe, only scan for devices when a
conn= spec was provided. This avoids false positives and malfunction of
other devices, and still lets users address the problematic device. This
is similar to serial-dmm and unspecific cables and has proven to work
there.
How to reproduce the issue:
(while any auto enumerating SCPI device is connected)
$ sigrok-cli --scan
Pre-assign default values before having user specified options scanned.
This avoids the necessity to post-process the result. Move the initial
assignment to where its corresponding update is to improve readability.
The sr_serial_extract_options() routine is a hidden gem, has existed for
almost eight years, and is exclusively used by the motech-lps-301 driver
(was also used by hameg-hmo at some point in the past). Being so useful
and doing something to terribly popular, more drivers should use it.
Extend the API to make either of the out parameters genuinely optional,
and guarantee that pre-assigned defaults will survive in the absence of
user specs. Update the Doxygen comment.
While queries for the range are supported for voltage, current,
resistence, capacitance, the same queries in temperature, frequency,
diode, continuity modes not only fail but even lose the USB connection
to the device. This was consistently observed with 34405A and 34465A.
Suppress get and set range requests for the known problematic modes of
the Agilent protocol speaking meters.
Although the 34405A does not support this function, other Agilent
protocol using meters do (currently 34465A, very probably others which
are about to get added in the future).
It's assumed that announcing the availability of that MQ for a set of
meters while only some of them support it is preferrable over exploding
numbers of copies of tables which only slightly vary among each other.
This mechanical edit adds a flags field and the initializer element to
make the compiler happy. Behaviour does not change. See a word diff for
improved review experience.
Add support to get and set the auto/manual range on Agilent protocol
speaking devices (34405A, 34465A). The range values are mere numbers
without a unit or MQ associated with them. Support to list available
ranges is prepared but not used (not needed on these meters). Common
logic could open code the lists of ranges from the model description
if desired in a future implementation.
Though measurement values come in, the 34405A and 34465A meters kept
beeping when acquisition is started. Stopped beeping when the MEAS
keyword was changed to INIT, which is used for other Agilent devices
using the HP protocol variant.
This change is acceptable because it was tested on all DMMs which use
the Agilent protocol (according to scpi-dmm profiles).
Increase the default digit count in the 34465A model description. Though
most measurements get the precision from the current reading, this data
is used as a fallback when the response won't provide the detail.
Assume that *IDN? requests don't involve expensive processing, and thus
don't require *OPC? before their execution. This makes scpi-dmm follow
the good tradition to only use non-standard or model dependent features
after the device was successfully identified. Which avoids confusion on
unrelated devices.
Exclusively check for *OPC? availability on Owon devices, because these
motivated the introduction of the test in the first place. This avoids
confusion on other devices where short timeouts result in errors because
the response is not retrieved although the command is supported (observed
on Agilent meters connected via USBTMC).
Improve readability of SCPI uint8 and float vector get routines. Move
assignment and use of variables closer together to simplify review.
Allocate the glib array based on the text split result's length. Move
data processing to the "straight" path and handle failed conversion as
an exceptional condition in an error path.
Eliminate a redundant data type reference in a malloc call.
The SCPI get routines may allocate memory for response data which
callers have to free after use.
The implemented approach is modelled after pull request 114 by
Matti Eiden, to get the leak fixes in while the PR is queued.
This addresses part of bug #1683.
Submitted-By: Matti Eiden <snaipperi@gmail.com>
The SCPI get routines may allocate memory for response data which
callers have to free after use.
Move an existing assigment such that the initial assignment, the memory
allocation, use of response data, and resource release are in closer
proximity, and thus are easier to reason about during maintenance.
Behaviour does not change.
This is motivated by bug #1683.
The SCPI get routines may allocate memory for response data which
callers have to free after use.
The approach to release allocated memory is simlar or identical to the
corresponding parts of pull request 95, in an attempt to get the reported
leak fixes in, yet reduce the potential for conflicts where this commit
deviates from the PR. Most work was done by Ralf. Thank you!
This addresses part of bug #1683.
Submitted-By: Reported-By: Ralf <jr-oss@gmx.net>
Tested-By: Reported-By: Ralf <jr-oss@gmx.net>
The SCPI get routines may allocate memory for response data which
callers have to free after use.
Move an existing release call to an earlier location, to avoid leaking
memory when an error path is taken.
This addresses part of bug #1683.
The SCPI get routines may allocate memory for response data which
callers have to free after use.
This implementation is incomplete. The fluke-45 driver's context holds
a "global" copy of the most recently received response. While the data
is freed in the next receive call, one item remains allocated for the
driver's remaining life time. Which is considered non-critical.
Also moves an operator in a complex multi-line expression to a different
location to follow the project's style.
This addresses part of bug #1683.
Some of the SCPI getter routines allocate memory for response data which
callers need to free after use. Document this responsibility in more
places, and rephrase existing locations for consistency. See a word-diff
for the essence of the commit.
It's assumed that the separate paragraph in the function description is
better perceived than something that's hidden in the parameter or return
value discussion. Also reference the corresponding free routine by name
for callers' convenience (data types will differ among routines). Some
free routines can be called unconditionally, others require NULL checks
at the caller's.
Reported-By: Ralf <jr-oss@gmx.net>
Assign NULL early in those SCPI get routines which return allocated
memory to their callers. So that the return value is either a valid
pointer to memory or NULL regardless of the routine's exit code. This
simplifies call sites and increases robustness.
Opening a serial port involves two libserialport calls, while only the
second call's return value gets inspected. Check the lookup before the
open, too, and provide its details in a diag message.
When CSV import grabs channel names from the first line in the file then
the text strictly between column separators (a comma) was used. Which
resulted in channel names like " channel 1". Trim leading and trailing
space before unquote, to better fulfill most users' expectation. Users
still can quote the input data for special cases if desired.
The DPS devices default to a rather low UART communication bitrate. The
generous retrieval of more Modbus registers than strictly necessary for
the periodic acquisition of analog channel values and state tracking may
or may not be an issue.
Instrument all call sites in api.c to the device state gathering calls
such that the protocol.c side transparently can reduce the transfer
volume depending on which level of detail the caller may expect given
its current context. Under optimal circumstances this might cut the
traffic in half, which DPS devices may benefit from.
This commit adds the infrastructure to potentially reduce transfer
volume, but does not change behaviour. The "config" reasons may need
further partitioning if Modbus register access really turns out to be
a severe bottleneck. The API lends itself to that extension easily. The
approach which gets prepared in this commit needs to get runtime tested
by those who got access to the hardware.
The RD devices differ from DPS devices in their default communication
bitrate (115200), register content endianess (BE), and register set
layout (addresses for registers). In either case 16bit registers get
accessed by means of Modbus communication over a serial channel. The
interpretation of the registers' values mostly is the same as for DPS
devices once a register with the same meaning got identified. Device
identification includes a 32bit serial number which DPS devices appear
to not provide.
All other product features are the same, and map to identical sigrok
mechanisms. That's why re-using the rdtech-dps driver to add rdtech-rd
support is considered desirable. This implementation shares all code
"above" the raw register addressing and raw value interpretation. All
logical processing, configuration interface, state tracking and data
submission to the session feed, are shared among the different device
types.
Declare support for the RD6006, RD6012, and RD6018 models. Their specs
were taken from the 2020.12.2 instruction manual. The driver was tested
with an RD6006 device (firmware version 1.28). Unfortunately automatic
device detection is not possible or will not be reliable, which is why
users need to specify the respective model by picking one of the two
drivers. Within a driver variant the device identification and use of
the device are automatically dealt with.
The existing power supply driver for Riden DPS/DPH devices unfortunately
duplicated intimate details of modbus communication and register layout
including interpretation of raw register values across several source
files. Do separate the physical transport and the register layout and
register fields interpretation layers. This brings the driver in line
with the usual api.c and protocol.c arrangement of responsibilities, and
prepares the future addition of other similar devices.
Address a few style nits while we are here. Include <config.h> in all
source files, and alpha-sort include directives. Address minor data type
nits. Reduce indentation in code paths. Propagate more error codes.
Update comments which lagged behind the code, adjust grammer (eliminate
"actual" false friends). Eliminate a few magic numbers and redundancies,
switch to the more recent endianess aware byte stream reader API where
beneficial, to eliminate redundant offset math.
Other nits seem to have gone unnoticed before: The indices of all sigrok
channels were identical (all zero). Signed print formats were used for
unsigned data.
This implementation compiles, but wasn't runtime tested due to lack of
hardware. A rough estimate of transfer volume and transport throughput
suggests that the 10ms cycle time no longer can be kept, may end up
around 25ms (40 cycles per second). This can get avoided by adding more
code to tell the configuration requests, the acquisition start, and the
measurements grabbing during acquisition apart. It's assumed though that
the 10ms glib poll interval did not translate to such fast measurement
gathering. The firmware may typically provide data at lower rates anyway.
The generic source code may look overly complicated or redundant at
first glance, but compilers' generated code will greatly get optimized.
Simplified maintenance because of reduced cognitive load is considered
more important.
Improve readability by addressing the trivial style nits in the driver.
Break the channel list into two times eight instead of nine plus seven
items. Put braces around all branches if one of them has braces. Add
braces to multi line branches despite most of the branch just being a
comment -- it's still many lines. Break extra long text lines, adjust
the position of operators when single expressions span multiple lines.
Drop unnecessary parentheses around single variables and auto
incrementing pointer dereferences. Adjust whitespace especially for
pointer data types, and arith operators.
Eliminate packed structs in the construction and in the reception of
USB transfers, since these are rather non-portable. Use common support
for endianess aware access to byte streams instead. This unbreaks the
driver for MinGW builds, and increases portability and maintainability
on all other sigrok supported platforms.
[ gsi: adjust more locations, improve robustness, fixup style, reword message ]
The ezusb_upload_firmware() routine opens the USB device and selects the
current configuration. The specified value must match the previously read
configuration descriptor. This commit unbreaks the firmware download for
MinGW builds which link against libusb-1.0.20-rc3-event-abstraction-v4.
[ gsi: reworded commit message ]
The SCPI standard requires OPeration Complete command,
but some Owon meters do not implement it. This commit
makes the probe try OPC once, and if it gets no reply
it assumes it is not supported.
Try the identification command up to three times
if the device responds with 'Invalid Character.',
which can happen if the device has buffered part
of a command but not executed it.
Re-use HMP4000 options and channel groups, only keep separate channel
specs for HMP2000 devices. HMP2030 has three identical 32V/5A channels.
HMP2020 has one 10A channel and one 5A channel.
Specs published by R&S suggest that 10A channels support 0.2mA resolution,
while only 5A channels resolve to 0.1mA (up to 1A full scale, 1mA above 1A).
This fixes a bug where the channel group setting would not be overwritten in a
new run, but instead the channel group settings of both runs would be merged
together.
While the raw sample is the actual received data, the expanded sample is the
crucial data I as a developer am interested in seeing. At least if I assume that
the sample expansion works.
Introduce a DMM packet parser in src/dmm/ and register it with the
serial-dmm device driver. This adds support for the Meterman 38XR
multimeter.
[ gsi: style adjustment, raise awareness during maintenance ]
Make another code path in the Brymen BM52x packet parser optional which
snuck in earlier and broke compilation when serial_comm dependencies are
not met.
Ideally the src/dmm/ parser code would not get built at all in that
case, but building a parser with reduced functionality and not using it
later because its callers are conditional is as good, and is what other
DMM packet parsers did in the past.
How to reproduce:
$ configure --without-libserialport --without-libhidapi --without-libbluez
$ make
Capture does not stop for sample count values which exceed the range of
a 32bit type variable. Adjust the data type to 64bit.
How to reproduce: 8MSa/s * 600s -> 4,800,000,000 samples
$ sigrok-cli -d fx2lafw -o capture.sr --config samplerate=8M --time 600000
[ gsi: rephrased the commit message ]
Some FTDI chip based products ship with EEPROM content which makes
libftdi fail to lookup the USB strings, which breaks the scan for the
device's presence. The previous implementation was strict and only
accepted the absence of a serial number. This implementation also copes
when vendor and model cannot be gathered from the device, and provides
fallback values based on VID:PID numbers.
Also factor out a magic number for string lengths. Stick with dynamic
allocation since 3x 32bytes would be rather huge a local stack use, and
future maintenance might bump that string length again.
[ gsi: magic number in one spot, bounded string assignment, style nits ]
Submitted-By: Christo Crause <christo.crause@gmail.com>
Introduce a text to number conversion routine which supports non-decimal
bases and optional suffixes, but returns unsigned results and thus covers
a larger range of values. This kind of amends commit 97aa41e9b5 which
introduced the sr_atol_base() routine.
Check for the availability of the "no_reorder" linker attribute, which
keeps the list of builtin drivers in shape on LTO enabled build setups.
Keep backwards compatibility for platforms which lack support for the
"no_reorder" attribute. Phrase the implementation such that other
keywords as well as user provided external specs are possible.
This resolves bug #1433.
Submitted-By: Ivan Mironov <mironov.ivan@gmail.com>
The BM820s series uses the same 10000 counts protocol as BM520s does,
but lacks the capability of recording measurements. Re-use the bm52x
DMM packet parser, but don't register the config get/set/list and
acquisition start callbacks.
It turns out that the packet request and packet validity check routines
need to be individual, since 0x82 is used instead of 0x52 as a magic
number in some places. Fortunately the complex payload parser is shared
among BM520s and BM820s series. This was tested with a BM829s meter.
Extend the BM52x packet parser, add config get/set/list code to handle
the data source property. Either let the common serial-dmm code run the
acquisition of live readings, or locally retrieve the selected "session
page" and forward its measurements to the session bus. These separate
code paths are required because the protocol differs a lot between these
modes, a totally different set of requests and responses is involved,
response interpretation logic is impossible to share between live and
recorded measurements.
Implement a DMM packet parser for the BM850s protocol. This involves
variable length responses, which recently became a common serial-dmm
feature. Register the new parser under the "brymen-bm85x" device name.
This obsoletes the brymen-dmm driver which announces as "brymen-bm857".
This implementation was tested with the BM859s meter.
The text to number conversion with precision detection resolves the
last remaining issue of bug #1611.
Provide a common string helper routine which converts input text to a
double precision floating point number, and also gets its precision in
the process.
Extend the serial-dmm driver's common infrastructure to support more
per-parser (per-model) specific extensions. Add support for variable
length packets (motivated by BM85x), and pass the packet length to
parsers which accept it. Add callbacks which run after the COM port got
opened (motivated by BM85x). Add support for additional configuration
get/set/list properties (motivated by BM52x), including a hook into the
acquisition start and a state container which is owned by the parser.
Device specific acquisition start can check its local state which can
store the result of previous config get/set requests, and can arrange
for a different receive routine to execute (motivated by BM52x). The
default code path will execute serial-dmm's receive routine which keeps
invoking the DMM's packet parser for each registered display.
Prefer double precision values in the new parser callbacks. Also fixup
some data type issues: Use unsigned types for length and size specs as
well as timeouts, don't promote false booleans to NULL pointers, reduce
malloc() argument redundancy. Rephrase some instruction grouping and
update comments to simplify future maintenance. Get the current time
just once for improved consistency in the packet re-request code path.
Rename identifiers in the data reception path to improve readability.
The previous implementation of the packet detection in a serial stream
assumed that all packets are of equal length which is known in advance.
Extend the packet validity check interface such that caller provided
callbacks can either decide that the input is valid or invalid (terminal
decision), or request more receive data before a decision can be made
(deferral, coverring variable length packets, with a minimum size to
cover the header before a length becomes available and the total packet
length is known).
This commit extends the API, and adjusts the call sites to not break the
compilation. Actual variable length checkers are yet to be done. Improve
readability while we are here: Better reflect the purpose and units of
variables in their identifiers. Tweak diagnostics messages, update
inline and doxygen comments.
When the input data exclusively contained analog data, then creation of
the submit buffer for logic data caused a division by zero. Fix the
create_feed() routine.
Naive creation of VCD files with inappropriately fine timescale specs
results in excessive resource consumption due to libsigrok's assumption
of a constant rate stream of sample data. A workaround is available and
documented, but users need to become much more aware.
Implement a reliable check for wasteful input data situations which
depends on the reception of _all_ input data, and can only alert users
late after potentially spending lots of time and assuming that available
resources allow completion of the import. Users could miss that check's
outcome.
Also implement early checks which (necessarily) are based on weaker
conditions, to already raise user's awareness while data import still is
executing. Phrase these early checks as computationally inexpensive as
possible, to not affect the main task of data import too much. Avoid
false positives by balancing the desire for early emission of messages
and picking appropriate conditions to test for.
This commit implements the foundation for early estimates and reliable
terminal checks, as well as the emission of messages which support users
and allow a more effective use of the file format. The specific limits
and tested conditions still may benefit from more tuning in the future.
The input module logic in this commit emits an information for harmless
cases, and emits warnings for "severe" cases where default option values
or incomplete user specs result in several orders of magnitude higher
resource consumption than necessary. GUI users may not notice, but the
library cannot help that given the current infrastructure -- the library
stricly does as the application tells it to, according to user input.
The best use is to run the CLI's --show feature on VCD files of unknown
content, to get an idea how to most appropriately configure a subsequent
file import. An alternative is to open the VCD file before import, check
the timescale in the header and the last two timestamps, to get an rough
estimate of a useful downsample factor.
This is motivated by but does not resolve bug 1624.
The previous implementation already mapped L/H/U/- literals for input
data values to the 0/1/0/0 logic levels which sigrok can handle. But
missed these literals in the condition which dispatches real/integer,
bit vector, and single bit data types. Which made VCD import fail for
some of the files in the SpinalWorkshop repo.
Extend the test condition for single bit values. This unbreaks the
import of the Apb3TimerTester.vcd and ApbPwmTester.vcd files, which
contained phrases like these:
...
$var reg 1 % io_apb_pwrite $end
...
#0
bUUUUUUUU !
b0 "
0#
1$
U%
and
...
$var reg 8 # io_apb_paddr[7:0] $end
$var reg 1 $ io_apb_pwrite $end
...
#0
b0 !
0"
b-------- #
-$
b-------------------------------- %
b00000000000000000000000000000000 &
1'
Recent glibc-2.26 no longer provides support for SunRPC, and libsigrok's
build support failed to detect the presence of libtirpc in that case.
https://wiki.gentoo.org/wiki/Glibc_2.26_porting_notes/RPC_implementation
Extend the check, use either SunRPC or TI-RPC. Which re-enables VXI on
recent setups. This resolves bug #1473.
DG800/DG900 units seems to have issues with counter implementation:
- About 1 second delay is needed after enabling or disabling the counter.
Otherwise unit stops responding properly (start seeing USB errors).
- Second channel and counter cannot be enabled simultaneously.
Strictly speaking the "new" identifier is not a reserved word. Still
it's good practice not to use it for variables in C language sources.
Rename variables to "old_bit" and "new_bit" for consistency.
Rearrange the order of declarations in the protocol.h header. Start with
packet layout, continue with requests (commands), then responses (status),
before the device context and the set of routines.
Rename the status codes to STS_* in contrast to CMD_* codes. Use an enum
for different byte values, leave defines for packet sizes et al. Phrase
bit fields in terms of bit numbers not byte values.
Total nit: Change the breaks in the long list of add_source() args. Keep
event type and timeout together, similar to callback and its data.
Explicitly "break the flow" when internal status gathering fails, to
reflect that an error path is taken and the config call will fail. The
conditional assignment of response data in case of success could be
slightly misleading (it was to me during review).
Eliminate a goto which kind of circumvented the optional transmission of
a request to the device. Instead test whether a command was filled in to
determine whether a command needs to get sent.
This driver supports ITECH IT8500 series electronic loads:
IT8511+, IT8511A+,
IT8512+, IT8512A+, IT8512B+, IT8512C+, IT8512H+,
IT8513A+, IT8513B+, IT8513C+, IT8514C+, IT8514B+, IT8516C+
Additionally BK Precision 8500 series loads (models 8500, 8502, 8510,
8512, 8514, 8518, 8520, 8522, 8524 & 8526) should work as well.
As ITECH is the OEM manufacturer for these BK Brecision models.
Return SR_OK in case of successful transmission of a packet request. The
previous implementation passed the serial layer's verbatim return value,
which was non-negative non-null (read: above zero) in case of success,
which is none of the expected return codes of a packet request routine.
This amends commit 379e95c587 and completes the adjustment which was
started in commit a4be2b327b. The issue has gone unnoticed in the past
since it took not effect. The serial-dmm caller only tested for negative
return values.
Trailing whitespace in CSV cells broke the text to number conversion.
Trim the text content of cells before processing it. This is useful and
actually essential for data cells, and does not harm titles in header
lines, neither will it affect column format specs.
How to reproduce:
$ echo ' 3.14 , 2' | \
sigrok-cli -i - -I csv:header=false:column_formats=2a
sr: input/csv: Cannot parse analog text 3.14 in column 1 in line 1.
Reading output signal duty cycle value didn't always work, since it relied
on old (cached) information about the currently active waveform. Changed to
always query channel status so this won't happen anymore.
Data was sent to the serial port, and the non-zero positive write length
was mistaken as an error, since it did not match the SR_OK code's value.
This snuck in with commit 379e95c587 in 2017-08.
Rephrase the check for successful serial writes in the pce-322a driver.
Pass on error codes from the serial layer in verbatim form. Check for
the exact expected write length and derive SR_ERR_IO upon mismatch. Do
return SR_OK upon success.
Reported-By: Michael Ströder <michael@stroeder.com>
Tested-By: Michael Ströder <michael@stroeder.com>
No need to duplicate the data type, just allocate enough memory to
hold the variable's value. Shuffle the order of items in the array
size calculation (number of items times the size of an item).
This implements support for Rigol DG1000z series digital signal
generators. Driver provides basic control via channel groups
("1", and "2"). Acquisition returns data from the built-in
frequency counter.
Supported models: DG1022Z, DG1032Z, DG1062Z
[ gsi: added some coding style adjustment ]
MSO5000 returns memory depth value in that format, e.g.
sr: [04:21.491949] scpi_vxi: Successfully sent SCPI command: 'ACQ:MDEP?'.
sr: [04:21.501463] scpi: Got response: '4.0000E+03', length 10.
[ gsi: drop redundant assignment and parens, amend diag message ]
Reduce the message's log level from ERR to INFO when the serial stream
detect routine cannot find a valid packet. Although an error code gets
returned, the condition need not be fatal (can be the result of trying
several peers before success or finally giving up). Let callers decide
on the severity of failure to detect a specific device's presence, and
provide more context in their message which is more helpful to users.
Interested readers still get the message at slightly raised log levels.
This avoids confusing user perceivable situations like these:
$ sigrok-cli --scan
sr: serial: Didn't find a valid packet (read 0 bytes).
sr: serial: Didn't find a valid packet (read 0 bytes).
The following devices were found:
demo - Demo device with 13 channels: D0 D1 D2 D3 D4 D5 D6 D7 A0 A1 A2 A3 A4
Use the existing ols_send_reset() routine because acquisition
termination can get initiated in several code paths. Make sure the
device will cease activity whatever state it happens to be in. This
amends commit 6d8182b643.
Sending CMD_RESET will interrupt armed/untriggered acquisitions which is
very useful in Pulseview sessions since, without this, a next 'run' will
hang.
Signed-off-by: Ben Gardiner <ben.l.gardiner@gmail.com>
The reference impedance for dBm measurements comes in an unexpected
format. Isolate the 4..1200 Ohms value, ignore the (inappropriate?)
"0." and exponent parts of the response. Clearly reflect that Ohms
values are seen in different contexts (dBm reference, continuity,
resistance).
Reword comments in the BM850 response parser's code path for dBm
measurements. The reference value is shown when the function is entered
(verified here) or when the reference value changes (haven't seen this
here but a comment in the previous implementation said so).
The BM850s temperature function response includes the C/F unit in an
unexpected position ("0.0272CE+3") which breaks number conversion. Drop
the C/F unit to unbreak the conversion.
This was observed with BM859s. Absence of the C/F unit in the response
is fatal in this implementation. If other meter firmware versions or
models don't suffer from that issue, the removal must be silent and
non-fatal.
When the BM850s response packet's payload gets interpreted, the DLE/STX
transport envelope is not of interest. Rephrase the bitfield inspection
to better reflect that 'bfunc' indicators get accessed (match the vendor's
documentation). Rephrase the calling parse routine to unobfuscate the text
field access. Unclutter assignments for the analog feed. Use a shorter
layout in debug messages, reflect raw input data and conversion results.
The BM850(a/s) response packets are a mix of binary and text content.
The text part of it is _not_ a regular ASCIIZ string. Enforce the NUL
termination before running standard C library string routines on it.
Rephrase the conversion routine to become more C idiomatic.
Also check the optional sign for overflow conditions, return either
positive or negative infinity as a result.
Rephrase how the default serial communication parameters get applied.
Preset the variable to the default value and let optional user provided
specs override these. This avoids an extra check which is difficult to
read and highly redundant. Add a comment for raised awareness that a
default port spec is undesirable because it's unreliable.
Raise the severity of low battery messages. It's worth warning the user
because measurements could be inaccurate.
Reduce indentation in continuation lines of a long routine signature,
and drop an empty line in a short struct while we are here.
Either the Brymen meters in the BM850s series or their cables require an
RTS pulse to wakeup, without it there won't be a response during scan or
when requesting measurements. Follow the vendor's documented sequence for
a low RTS pulse after opening the serial port and before communication to
the device.
This fixes bug #1595.
Reported-By: Karl Palsson <karlp@tweak.net.au>
Introduce a routine in libsigrok's internal serial layer which lets
applications manipulate the state of handshake signals (RTS and DTR)
after the serial port got opened and configured. This allows for timed
pulses which cannot get expressed with static "rts=1" etc phrases in
parameter strings, and allows handshake signal control while leaving
bitrate and frame format untouched. Applications specify which signals
to modify while other signals remain as they are (ternary input).
Do implement the signal manipulation in the libserialport transport,
do nothing and silently pass in the HID and BT transports. These can
get extended later as the need arises, depending on the HID chips' and
RFCOMM peers' capability to control these signals. This extension is
transparent to application code (acquisition device drivers).
Use positive logic, put the error path for an unavailable value where
the check for its availability is. Do the regular activity on available
values in the straight code path with lesser indentation. Also group the
bitrate, frame format, and handshake params when breaking text lines.
Introduce a bm52x DMM packet parser which is modelled after the bm86x
implementation, and hook it up to the serial-dmm driver. This supports
the live readings (real-time download) of the Brymen BM525s logging DMM.
The timing follows the vendor documentation (0.5s between requests, and
4.0s absolute timeout after request transmission). Reading previously
recorded data (memory data sets) unfortunately does not fit well into
the serial-dmm approach, and needs to get addressed differently later.
Common conversion support code accepts double precision input data for
analog packets. Use the 'double' data type in the CSV input module to
feed sample data to the session bus.
Rephrase the sr_analog_to_float() routine to further reduce redundancy.
Check early for a match of the input data and result format, to grab the
raw data without conversion in that case. Handle optional scale/offset
calculation in that fast code path, too.
Unify the instructions which convert input data from either integer or
floating point presentations to the result format. Use common stream
readers to retrieve input data in several formats, which eliminates
local conversion buffers. Move common sub-expressions (scale/offset) out
of loops. Run more calculations on double precision data before results
get trimmed to single precision.
Add and extend comments to improve future maintenance. Include (terse)
details of unsupported input data presentations in error messages.
This implementation was neither tuned nor measured for performance.
There still is a lot of redundancy among the branches which handle a
specific input data type. Rephrasing that approach interacts with the
yet to be done performance tuning, thus needs to get addressed later.
The current phrases' verbosity is believed to improve readability.
Add endianess aware readers including address incrementing variants for
those intrinsic data types which were missing in the previous version
yet are needed for sr_analog_to_float() adjustment.
Also move the 24bit reader to its position in the sort order.
Extend test coverage for the sr_analog_to_float() conversion routine.
Pass data which is encoded in native, little and big endian format to
the routine. Pass single and double precision floating point data, and
integer data in different unit sizes and signedness. Cover scale/offset
calculations as well.
Also cover expected failed conversion for unsupported combinations of
input data format details (half/quad precision float, u64 integer).
Adjust the grouping of test cases in the sequence while we are here.
Move SI prefix, unit, and rational number related tests out of the
analog-to-float conversion group.
Unbreak the conversion of input data in the floating point format when
the input data's format does not match the host's internal presentation,
thus grabbing raw data cannot be done.
Also accept the input data in double precision format which was not
supported before. Check for unsupported unit size values and emit an
error message similar to the integer code path.
This is motivated by bug #779 but does not resolve it. Adjusts common
conversion support, but sticks with single precision return data type
for API compatibility.
We pass no message, so use ck_assert instead of ck_assert_msg. This
results in an error with check 0.15:
tests/strutil.c:157:2: error: too few arguments to function '_ck_assert_failed'
157 | ck_assert_msg(saved_locale != NULL);
The Saleae Logic exported files (Logic2 digital format) don't contain a
samplerate, so users need to specify the value. For values smaller than
the samplerate that was used during the capture undersampling will take
place. An implementation detail of the input module could result in
incorrect timing of sample values in the session feed. In extreme cases
none of the periods between signal edges qualified for submission. In
that case no sample data was sent to the sigrok session at all.
$ sigrok-cli -i digital_1.bin -I saleae:samplerate=1000
Keep the very timestamp at hand when the last sample data was submitted.
Only advance that timestamp when more sample data was sent. This avoids
the accumulation of timing errors for undersampling scenarios, and does
forward undersampled input data when the user provided sample period has
passed.
This fixes bug #1600.
The korad response read routine clears the receive buffers, so callers
don't have to. This amends commit d2cc60bd45.
The acquisition timeout is handled by common sw_limits support. Remove
the no longer referenced literal. This amends commit 3f9b48ae5f.
The Korad protocol relies on unterminated request and response strings,
which works well enough for fixed length acquisition and status queries.
But the variable length replies to identification requests suffered from
an implementation detail in the receive routine. A large timeout must be
used because supported devices reportedly are slow to respond. There is
no simple yet robust condition to detect the response's completion. The
scan code must prepare for the maximum response length across the set of
supported devices. Unfortunately the maximum amount of time was spent
waiting for the response to occupy the provided response buffer, before
a long total timeout expired.
Rework the korad driver's helper routine which gets a variable length
non-terminated text string. Keep the long initial timeout, and keep
iterating in that initial phase to quickly detect when response data
became available. But terminate the read sequence after a shorter period
without receive data after some initial receive data was seen. Assume
that identification responses get transferred at wire speed and without
additional delays beyond bitrate expectations. Acquisition and status
responses shall not be affected by this change.
This speeds up the scan for devices from roughly 5s to some 0.1s on
newer devices (KA3005P v5.5) and 0.5s on older devices (KA3005P V2.0).
This commit also addresses an issue in the response text termination,
where partial responses contained undefined data. The previous version's
return value was unspecific: Negative for fatal errors, but either zero
or non-zero for successful reads, with no way for callers to learn about
the received amount of data. The rephrased version always returns the
amount of received data, and adds internal documentation which discusses
the implementation's constraints and the motivation for the approach.
This is a modified version of the initial implementation which was
Submitted-By: Karl Palsson <karlp@tweak.net.au>
Cleanup style in the korad driver's scan() routine. Keep declarations
out of code blocks. Reduce redundancy and improve robustness in the
response buffer length calculation. Reduce clutter and group related
instructions together. Unobfuscate result checks, and keep the result
at hand (for diagnostics, or error propagation). Unobfuscate string
comparisons in the model ID lookups, terminate the search upon match.
Use a not so terse name for data that gets referenced at rather distant
locations.
Keep the optionally available serial number at hand, to present it to
users when desired. This aspect was
Reported-By: Karl Palsson <karlp@tweak.net.au>
The previous implementation of the cleanup() routine in the saleae input
module kept user specified options, but lost the previously created list
of sigrok channels. Keep it.
Also make sure that reset() voids the previous copy after grabbing its
value. To not unexpectedly release resources which still get referenced.
This shall unbreak file-reload.
Stop using the unusal "mixed" mode (local interface available during
remote operation) for HMP4000, applications may not be prepared for this
use case. Use traditional "remote" and "local" modes instead. This change
also ends remote mode after the application is done using the device.
List both vendor names "HAMEG" and "ROHDE&SCHWARZ" in the scpi-pps
driver, either responses were seen for HMP4000 devices. Unfortunately
vendor names don't support regex matches, so they require individual
profile items. The items also "violate" the alpha sort order in the list
of profiles, but keeping the series' models together is more important.
Add a declaration for the HMP4030 device which re-uses the HMP4040 data
but open codes the smaller channel count. Ideally the .probe_channels()
routine would receive the scpi_pps item as a parameter, and could yield
model specific result data from common information for the series. The
implementation in this commit is the least intrusive approach until
something better becomes available.
This shall cover the whole HMP4000 series:
https://www.rohde-schwarz.com/product/hmp4000
This commit introduces initial support for the HMP4040 power supply by
Rohde & Schwarz. It allows to configure the device and "statically" read
back current state. Automatic status updates with per-channel details
are not available yet (common support is missing).
[ gsi: drop status update remainder, address minor style nits ]
Reference the vendor's Windows specific "driver" download for the
CP210x chip with a non-default VID:PID. Provide an example how to
assign the Linux driver to that device (interactive, no udev rule).
In the current implementation the "flags" are exclusively used for
captures. Prepare the introduction of device flags by renaming the
capture related flags which are specific to an operation.
Reviewed-By: Wolfram Sang <wsa@kernel.org>
Unconditionally generate output text when a session packet is received
which carries analog or logic sample data. Even if the data gets queued
and is not shown immediately, in that case the output text remains empty
but needs to be present. Otherwise applications may assume that the CSV
output module had not handled the data at all, which would result in
unexpected "screen output" with fallback data being interleaved with the
CSV output.
This resolves bug #1026 in its strictest sense (the unexpected presence
of fallback data). But leaves all other issues mentioned in comment 1.
The current implementation of the CSV output module makes assumptions
which don't hold. Which results in incorrect or incomplete output for
some combinations of logic and analog signals.
Check for some of the known problematic conditions, and warn the user
about potentially unexpected results. This is a workaround until the
issues properly get addressed in the implementation.
This is motivated by but does not resolve bug #1026.
Korad PSU models are rather popular. But the successful operation of
currently unsupported model names or firmware versions is hard to verify
by users, because building the library from locally modified sources is
involved.
Introduce support for the "force_detect=" scan option. Warning messages
contain how the device identifies itself. Optional user specs can force
the assignment of the driver to the unsupported model. Which results in
reports that include the identification details as well as the successful
use of the device.
$ sigrok-cli -d korad-kaxxxxp:conn=...:force_detect=KORADKA3005PV2.0 --show
Often previously unsupported models might be covered by existing code,
but would not match against a builtin list of known devices.
Introduce a config key which provides a scan option for users to force
the use of a driver with an unsupported device. This increases the
probability of requests for support of an additional model which are
associated with a successful use of that very device, and eliminates
the necessity to build from source for the trivial cases.
It's up to individual drivers whether they support forced detection,
and how they interpret the value of the scan option.
Let applications query the device instance's conn= key. This lets users
recognize individual devices if multiple of them are connected.
$ sigrok-cli -d korad-kaxxxxp:conn=/dev/ttyACM0 --show
...
korad-kaxxxxp:conn=/dev/ttyACM0 - Korad KA3005P with 2 channels: V I
...
Add new command DMM_CMD_SETUP_LOCAL for setting device back
to "local" mode. If device implmements this command, it is
sent when driver is closed and after device "scan".
Define DMM_CMD_SETUP_LOCAL for GWInstek meters, so they get
returned to local mode automatically after use.
Any order is as arbitrary as any other. The alphabetical order of vendor
and model names might be the most robust during maintenance: easiest to
remember, easiest to use when checking for presence, and easiest to add
to or resolve conflicts during merges. Vendor renames (HP to Agilent to
Keysight, et al) are ugly but can't be helped easily.
Address minor style issues: Need not assign NULL after g_malloc0(), need
not check for NULL before g_free(). Rephrase diagnostics messages which
are user visible by default, remove internal development details. Reword
a few comments, and adjust their grammar for consistency across the code
base. The sr_analog_init() routine executed immediately before getting
measurements, need not (re-)assign endianess or floating point details,
except those which do change after initialization (double vs float).
Rephrase model dependent checks for easier adjustment during maintenance.
Unobfuscate string comparisons.
Raise the diagnostics message's severity from debug to warn when the
'*IDN?' response lacks the serial number field. Although it has only
been seen for some GWInstek DMMs, it violates the SCPI spec, and more
or other activity is required in a future implementation. This change
amends commit 47e7a6395e.
Rearrange the check for line termination in SCPI receive data, and add a
comment in that spot. Keep related conditions together, avoid line breaks
for complex terms. This shall simplify review, and raise awareness during
maintenance. This change amends commit a0ade2f933.
Rephrase the logic which turns HIDAPI paths returned from enumerations
into something that can be used with conn= device options. Rearrange
code paths and rename variables to hopefully increase readability, and
to prepare support for more conditions in future implementations.
Replace the "IOService:" prefix on recent Mac versions with the "iokit="
literal, to eliminate the previously unhandled colon in path names. This
resolves bug #1586.
Move the allocation of a writable buffer from the callers to the callee,
to simplify multiple call sites, and most of all because the caller need
not be aware of the buffer's required size (input and output size can
differ in either direction).
Update the conn=hid/ section in README.devices, add the iokit= prefix.
Unbreak the timestamp calculation when session data is received in
multiple packets. Avoid a division by zero when the samplerate is not
known yet the time column is requested. Only calculate timestamps when
the time column is requested. Use floating point during the scaling,
only convert to integer immediately before printing. Change line breaks
to not split a complex sub-expression across several lines.
The conversion of sample rates to sample periods and the repeated
addition of truncated values (integer variables) resulted in the
accumulation of errors in the timestamp column for odd samplerate
values. How to reproduce:
$ sigrok-cli -d demo:analog_channels=0 \
-c samplerate=6000000 --samples 1200001 \
-O csv:time=true | tail
Accept the additional cost to reduce the error. Always get the timestamp
in a new calculation based on the sample number and the sample rate.
This addresses bug #1027.
Signed-off-by: Earle F. Philhower, III <earlephilhower@yahoo.com>
[ gsi: rephrased commit message, how to reprodue ]
Commit cb828f1b3e introduced an unconditional flush() call in the
open() routine's body, and passed its return value in verbatim form to
open() callers. Some of the transports/cables for serial communication
yield the SR_ERR_NA return value. Consider this a non-fatal condition.
Unbreak the CP2110 HID chip's flush() implementation. Don't expect a
return value of 0 from HID write calls, instead expect to see the number
of written bytes for successful calls.
This was tested with ch9325 (UT-D04), cp2110 (UT-D09) and bu86x.
Manufacturer revised hardware design without changing model numbers at some point.
Old units have firmware that behaves differently. Responses are terminated with \r
instead of \n. And STATUS? command response format is different.
Use size types for counters, unsigned for bit manipulation. Trigger
position needs to remain a signed int (must be possible to go negative
for "not here", and strictly remains within the output text line length,
so should be good).
Rephrase the nested loop during bit extraction from logic packets, and
how a channel's value at a given sample number gets accessed. Eliminate
redundancy in that spot, to improve readability and simplify maintenance.
Unobfuscate the implementation of the recent channel name alignment and
trigger position flush, address other style nits of earlier versions:
Don't need a GString for runtime constant channel names (which also
suffered from a mismatch of declaration and allocation). Don't need to
"construct space" when printf(3) can align the value. Pre-allocate text
buffers with more appropriate length when known in advance. Drop another
unused variable. Eliminate data type redundancy in malloc(3) calls. Make
sure to get zeroed memory, disabled channels can result in assignment
gaps. Use consistent brace style and separate variable declaration from
use (no RAII here).
Excess text line length remains, there has been a lot of it in the
previous implementation. It is left for another commit.
Tested with:
$ sigrok-cli -d demo:analog_channels=0:logic_channels=4 --samples 40 -O ascii -t D3=r -w
The trigger position would be missing in the output text when the number of
available samples is less than the configured text line length. Do flush the
trigger marker for the last chunk of accumulated samples, too.
How to reproduce:
$ sigrok-cli -d ... --samples 32 -O ascii:width=128
[ gsi: rephrased commit message ]
This results in vertical alignment of sample data and trigger positions.
The implementation assumes that the channel names' byte count corresponds
to the space which they occupy on screen. Channel names with umlauts still
may suffer from misalignment.
[ gsi: rephrased commit message ]
For pure analog acquisition without logic data the ZIP creation code
path resulted in a division by zero. Skip the bytes to samples math in
that case. How to reproduce:
$ sigrok-cli -d demo:logic_channels=0:analog_channels=1 --samples 20 -o file.sr
Avoid a dependency on malloc(0) behaviour while we are here. Add a
warning on data feed submitter implementation issues, to not silently
drop the data, which could surprise users. This ShouldNotHappen(TM) for
correct implementations where channel counts and unit size agree, but
was observed with incomplete out-of-tree implementations. Eliminate
a data type redundancy in another malloc() call.
Quite some drivers flush the serial port after opening it. And quite
some don't although they should. Factor this out, so serial_open() will
always flush the port. The removal in the drivers was done with this
small coccinelle script:
@@
struct sr_serial_dev_inst *serial;
@@
serial_open(serial, ...)
... when != serial
- serial_flush(serial);
and then the results and the unmatched findings of serial_flush() were
audited.
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Eliminate the dependency on the non-portable bt_put_le16() routine. It
isn't available in all supported BlueZ versions, and won't be available
in other platform backends. Prefer write_u16le() which is available on
all sigrok supported platforms.
Only return OK from the format match routine when either of the tested
conditions reliably matched. Return an error in all other cases. This
avoids that the Saleae module is "winning a contest" due to even the
weakest condition, and then is not able to handle the input file.
Start the implementation of an input module which covers Saleae Logic's
export files. CSV and VCD are handled by other modules, this one accepts
binary exports for Logic1 digital data (every sample, and when changed),
Logic1 analog data, Logic2 digital data, and Logic2 analog data.
The newer file format versions contain header information and can get
auto-detected, the older formats require a user spec. Some of the file
formats lack essential information in the file content, thus require
another user spec (samplerate for digital data is an example).
The .logicdata file format is unknown, and is not supported. The .sal
format could get added later, but requires local file I/O in the input
module, which current common infrastructure does not provide.
Extend the common set of endianess conversion helpers. Cover readers and
writers for little endian single and double precision and 64bit integer
values, including support to advance the read/write position.
Rephrase the default value for the 'skip' option and the detection of a
user specified value. This is tricky because: Sample numbers are kept in
64bit values. Skip and downsample are fed to formulae so we want them
both to be unsigned. Yet absence of a user spec as well as possible user
values 0 and positive must be told apart. Use all-ones for the default
of "-1" which translates to "first timestamp", users need not be able to
specify that negative value.
Make sure to only downsample 'skip' values when the user specified some.
Which avoids the undesired insertion of huge idle gaps at the start of
the capture. An earlier implementation had to check for -1, this recent
version uses an unsigned number in combination with a boolean flag to
achieve this.
Reword some diagnostics messages, and print the samples count between
timestamps while we are here. Add a check for successful text to number
conversion of timestamp values.
How to reproduce:
$ pulseview -i file.vcd
$ pulseview -i file.vcd -I vcd:downsample=5
$ pulseview -i file.vcd -I vcd:skip=111381600
Example file:
$timescale 1 ns $end
$scope module top $end
$var wire 1 ! d1 $end
$upscope $end
$enddefinitions $end
#111381815
0!
#111381905
1!
#111381990
0!
#111382075
Accumulate samples from multiple session feed packets before sending
them off to ZIP archive operations. This improves throughput for those
setups where acquisition devices or input modules provide only few
samples per session feed send call.
This version also splits large packets from applications into smaller
ZIP members (if the application's packet size is larger than the output
module's local buffer size). If that is not desired, the implementation
needs adjustment to immediately pass larger blocks to ZIP operations
(after potentially flushing previously queued data) instead of looping.
This fixes bug #974.
Extend and rephrase the VCD output module, to support mixed signal data,
support higher channel counts, and address other minor issues.
Increase the number of VCD identifiers which can get generated. Bump the
limit from 94 to 18346 channels. Prefer single letter names for backwards
compatibility for the first channels. Use two or three letter identifiers
as needed for higher channel counts.
Add support for analog channels, and carefully organize a queue such
that timestamps and their data only get written after input data for
_all_ channels was received from the session feed. Provide IEEE754
double precision values for maximum compatibility with other VCD aware
software, although sigrok internally passes analog data with single
precision. This makes potential later adjustment transparent to external
software.
Factor out and rephrase code while we are here. This implementation
avoids glib calls where they'd hurt performance. A local pool reduces
malloc() pressure to increase throughput. String manipulation is tuned
for simplicity and reduced cost. Special code paths were added to tune
the use cases where mixed signals are not involved (immediate write to
the output text, bypassing the output module's local queue).
An srzip input implementation detail still makes the VCD output consume
lots of memory during merge sort of channels' data. See bug #1566.
Other nits got addressed in bypassing: Adjust data types. Separate the
gathering of detail information and the construction of the VCD header
text to simplify review and future maintenance. Skip VCD identifiers for
disabled channels. Emit a final timestamp to flush the last sample, and
communicate the total capture length.
Update comments. Update the copyright for recent non-trivial changes.
Extend and rework the VCD input module: accept more data types, improve
usability, fix known issues.
Add support for bit vectors (arbitrary width), multi-bit integer values
(absolute 64bit width limit, internal limitation to single precision),
and floating point numbers ('real' in VCD, single precision in sigrok).
Unfortunately sigrok neither has concepts of multi-bit logic channels
nor IEEE-1364 stdlogic values, the input module maps input data to
strict boolean and multiple logic channels. A vector's channels are
named and grouped to reflect their relation. VCD 'integer' types are
mapped to sigrok analog channels. Add support for scoped signal names,
and the re-use of one VCD signal name for multiple variables.
Rework file and text handling. Only skip pointless UTF-8 BOMs before
file content (not between sections). Handle lack of line termination at
the end of the input file. Process individual lines of input chunks,
avoid glib calls when they'd result in malloc pressure, and severely
degrade performance. Avoid expensive string operations in hot loops.
Rearrange the order of parse steps, to simplify maintenance and review:
end of section, new section, timestamp, data values, unsupported. Flush
previously queued values in the absence of a final timestamp. Unbreak
$comment sections in the data part. Apply stricter checks to input data,
and propagate errors. Avoid silent operation (weak warnings can go
unnoticed) which yields results that are unexpected to users. Unbreak
the combination of 'downsample' with 'skip' and 'compress'. Reduce noise
when users limit the number of channels while the input file contains
more data (keep a list of consciously ignored channels). Do warn or
error out for serious and unexpected conditions.
Address minor issues. Use common support for datafeed submission. Keep
user specified options across file re-load. Fixup data type nits, move
complex code blocks into separate routines. Sort the groups of routines,
put helpers first and concentrate public routines at the bottom. Extend
the builtin help text. Update comments, update the copyright for the
non-trivial changes.
Fixes bug #776 by adding support for bit vectors.
Fixes bug #1476 by flushing most recently received sample data.
Input modules often find themselves in the situation where sample data
was received and could be sent to the session bus, but submission should
get deferred to reduce the number of send calls and provide larger data
chunks in these calls. Introduce common support code for buffered sample
data submission (both logic and analog), provide a simple alloc, submit,
flush, and free API.
The input/binary module chops raw input data into chunks and sends these
to the session feed. The total size of input chunks got aligned to the
unit size, the session feed output didn't. Make sure to align session
packets with the input data's unit size, too.
This fixes bug #1582.
This version is known to work with the current code-base and recent
SWIG versions, whereas e.g. Ruby 2.3.x is known to not work (anymore).
This "fixes" the remaining parts of bug #1526.
When using a number of frames that is not 1, the driver will read
samples up to its limit and then wait for another trigger. This will be
repeated until the configured number of frames has been finished.
This seems to make the Rigol DS1054Z work. It's still a bit janky --
on a live capture, sample 688 (zero-based) out of the 1200-sample
frame seems to consistently contain garbage. I'm not sure what's
going on.
The Rigol DS1054Z sometimes returns zero bytes in response to a bulk in
request. sigrok ends up reading out of bounds and failing ungracefully
when this happens. Check that libusb returned a full USBTMC header and
fail gracefully if it did not.
According to the programming manual, one should issue
:WAV:RES
:WAV:BEG
before reading data from internal memory. Without this, the wrong data
will be returned.
I want to fix this double-close issue I see with my OLS:
First close at the end of a 'scan':
sr: [00:00.045171] openbench-logic-sniffer: Got metadata key 0x00, metadata ends.
sr: [00:00.045178] openbench-logic-sniffer: Disabling demux mode.
sr: [00:00.045186] serial: Closing serial port /dev/ttyACM0.
Second one as part of hwdriver cleanup:
sr: [00:00.046088] hwdriver: Cleaning up all drivers.
sr: [00:00.046108] serial: Closing serial port /dev/ttyACM0.
sr: [00:00.046116] serial-libsp: Cannot close unopened serial port /dev/ttyACM0.
So, before closing a second time, check if the device is not idle.
I am optimistic this could fix bugs #1151 and #1275, too.
Signed-off-by: Wolfram Sang <wsa@kernel.org>
bindings/swig/doc.py generates a swig interface file for ruby bindings
that includes docstrings with comments braces ( /* and */ ) like this:
%feature("docstring") sigrok::Channel::type "/* Type of this channel. */\n";
%feature("docstring") sigrok::Channel::enabled "/* Enabled status of this channel. */\n";
SWIG generates *.cxx and adds its own braces to the docstring:
/*/* Document-class: Sigrok::Error
Exception thrown when an error code is returned by any libsigrok call. */
*/
this causes compilation error for Ruby bindings.
To fix the error we should not add extra braces to the docstring.
With this patch libsigrok compiles fine with with ruby 2.7 and swig 4.0.2.
Fixes bug #1526
Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
- always say 'ID' when the ID command failed
- print hexdump of a faulty ID because on a stalled device we may get
0x00 bytes which would terminate the string early.
Signed-off-by: Wolfram Sang <wsa@kernel.org>
This changeset adds support for the RDTech TC66C USB power meter.
Currently, the driver reports the following channels:
* V: VBus voltage
* I: VBus current
* D+: D+ voltage
* D-: D- voltage
* E: Energy consumed in threshold-based recording mode.
The number of significant digits shown for each channel has been set
to match the number of digits shown on the device.
Usage example:
sigrok-cli -d rdtech-tc:conn=/dev/ttyACM0 --scan
Known issues:
* BLE support is currently unimplemented. This uses a different
command set, but the same poll data format.
Kudos to Ben V. Brown for reverse engineering some of the protocol and
documenting the encryption key used for poll data.
Signed-off-by: Andreas Sandberg <andreas@sandberg.pp.se>
Being able to calculate a CRC16 is useful in multiple places, factor
this into a new module with CRC implementation. This module currently
only supports ANSI/Modbus/USB flavor of CRC16.
Signed-off-by: Andreas Sandberg <andreas@sandberg.pp.se>
This changeset adds support for the RDTech UMxx series of USB power
meters. The driver has been tested with the RDTech UM24C, but should
support the UM24C, UM25C, and the UM34C.
Currently, the driver reports the following channels:
* V: VBus voltage
* I: VBus current
* D+: D+ voltage
* D-: D- voltage
* T: Device temperature
* E: Energy consumed in threshold-based recording mode.
The number of significant digits shown for each channel has been set
to match the number of digits shown on a UM24C.
Missing features:
* There is currently no support for configuring threshold-based
recording from sigrok, but this can be done on the device itself.
* Fast charging mode currently not logged.
Usage example:
sigrok-cli -d rdtech-um:conn=bt/rfcomm/MAC --scan
sigrok-cli -d rdtech-um:conn=/dev/rfcomm0 --scan
Known issues:
* When using sigrok's Bluetooth transport implementation, the device
is disconnected between probing and sampling. Some devices (e.g.,
the UM24C), dislikes this and can't be reconnected reliably for
sampling. This is not an issue when setting up a rfcomm device
manually and using it as a serial port.
Kudos to Sven Slootweg for documenting most of the protocol.
Signed-off-by: Andreas Sandberg <andreas@sandberg.pp.se>
Many devices receive a struct with binary values when polled. Many of
these values will correspond channels in sigrok. This
change introduces helper functions for automatically reading and
scaling such values and sending them down a sigrok analog channel.
Signed-off-by: Andreas Sandberg <andreas@sandberg.pp.se>
The meter allows remote controlled start of recordings, but requires a
few parameters where it's uncertain how to most appropriately get these
by means of SR_CONF_* keys.
Introduce SR_CONF_SET support for SR_CONF_DATALOG to raise awareness,
but leave the implementation empty for now. Leave a TODO comment which
discusses the meter's commands that one might want to use from here.
Extend the previously introduced skeleton driver for UNI-T UT181A. Introduce
support for the full multimeter's protocol as it was documented by the ut181a
project. Which covers the retrieval of live readings, saved measurements, and
recordings, in all of the meter's modes and including relative, min/max, and
peak submodes. This implementation also parses compare mode (limits check)
responses, although it cannot express the result in terms of the session feed.
Announce the device as a multimeter as well as a thermometer, it supports
up to two probes including difference mode. When in doubt, prefer usability
over feature coverage (the driver side reflects all properties of the meter,
but not all features can get controlled by the driver). The probe routine
requires that users specify the serial port, and enable serial communication
on the meter.
Several TODO items remain. Comments in the driver code discuss limitations
of the current implementation, as well as cases where the meter's features
don't map well to sigrok's internal presentation. This implementation also
contains (optional, off by default) diagnostics for research on the serial
protocol.
When data patterns for trigger specs span multiple bits, users may not
want to specify long lists of "<ch>=<lvl>" conditions for sigrok-cli's
--trigger option, and count channels by hand. Or click a dozen dialogs
to specify one data pattern, or modify a previous specification. Setups
with few traces may accept that, "data heavy" setups like parallel data
or address bus inspection may not.
Add comments which discuss the potential use of SR_CONF_TRIGGER_PATTERN.
Outline a syntax which may be flexible enough _and_ acceptable to users,
support data patterns and edge triggers alike, in several presentations
that serve different use cases. This commit exclusively adds comments,
does not change behaviour.
Update a comment in the user spec to internal format trigger spec parser
to expand on hardware constraints and implementation limitations. Rename
an identifier which checks the number of edge conditions, not the number
of accepted trigger spec details.
Trigger support became operational again. Drop the compile time switch
which disabled the previously incomplete implementation.
This resolves bug #359.
Parse trigger specs early when acquisition starts, timeout calculation
needs to reflect on it. Either immediately start an acquisition timeout
for trigger-less configurations. Or prepare a timeout which spans the
post-trigger period, but only start its active period when the trigger
match was detected by the device's hardware.
Extend mode tracking during acquisition to handle other special cases.
Terminate acquisition when the user specified sample count limit exceeds
the hardware capacity, or when no limits were specified and the device's
memory is exhausted.
There is a slight inaccuracy in this approach, but the implementation
fails on the safe side. When both user specified limits and triggers are
involved, then at least the user specified time or sample count span is
provided. Usually more data is sent to the session feed, and all of the
requested period is covered. This is because of the software poll period
and the potential to start the timeout slightly late. As well as having
added some slack for hardware pipelines in the timeout calculation.
The previous implementation ran the complete sample memory retrieval
in a single call to the receive callback. Which in combination with
slow USB communication and deep memory could block application logic
for rather long periods of time.
Rephrase the download_capture() routine such that it can spread its
workload across multiple invocations. Run the acquisition stop and
resource allocation for the download, the interpretation of a set of
DRAM lines, and the resource cleanup, as needed. And keep calling the
download routine until completion of the interpretation of the sample
memory region of interest. The workload size per invocation may need
more adjustment.
The previous implementation could stall UI progress for some 20-30s.
This change lets users perceive UI progress while sample memory gets
retrieved and interpreted.
This resolves bug #1005.
Recent commits added "position tracking" for interesting spots in the
sample stream and the current iteration pointer. Which obsoletes the
counters for remaining items until trigger, the "triggered here" flags,
as well as the unfortunate "rewind a little" workaround which lacked a
comment on its motivation or implementation details.
The hardware provided trigger match location is inaccurate. Do check
sample values against the initial trigger condition spec for a short
range of the retrieved sample data, to refine the trigger marker's
position which is sent to the session feed.
Temporarily ignore the optional sample count limit for trigger-using
acquisitions, to reduce the diff size and simplify review. Since the
hardware transparently compresses sample data, we cannot reliably
determine where to start the download and interpretation of sample data,
and the submission to the session feed. Starting early in the sample
memory content, and sticking with the strict sample count limit, could
clip submission before the actual trigger position.
This implementation provides _at least_ the requested amount of data,
and does cover the spot of interest (the trigger position). This, and
the trigger support's having become operational again, is considered an
important improvement. The inaccuracy is considered acceptable for now.
Trigger-less acquisition does enforce the exact sample count limit.
Rephrase how the sample memory iteration position gets tracked, increment
after every event slot already. Update the "last seen sample" status more
often (an event slot can hold several sample items). Arrange for a period
of time where software will check sample data for trigger matches. This
improves the precision of the hardware provided trigger match location.
Do send hardware provided trigger locations to the session feed even if
the software check found no match on the data content. This covers user
initiated button presses (which can unblock the acquisition when the
application provided trigger condition never matches).
Note that this implementation does manage the window of supervision, but
does not yet check the sample values against the trigger condition. This
gets added later.
Factor USB data transfer out of the code path which interprets sample
memory content. Keep internal state of sample memory download in the
device context. This eliminates local variables, and ideally allows a
future implementation to spread chunked downloads across several read
callbacks, which would improve UI responsiveness.
Update comments while we are here. Address minor portability nits (ull
suffix vs UINT64_C macro). The inner loops (iterating clusters and their
events which contain individual samples) are not affected by this commit.
Further rephrase the sigma_write_trigger_lut() routine. It's helpful to
"think" in BE16 quantities to improve readability of LUT address and
parameter downloads. Better matches the vendor's documentation. Also use
a better name for the "trigger select 2" register content.
Start moving parameters into the device context which are related to the
interpretation of sample memory content. This can simplify error paths,
allow to release resources late. And ideally sample memory download and
interpretation could spread across several receive callbacks, improving
UI responsiveness. Also makes total and current dimensions available to
deeper nesting levels in the interpretation, which currently don't have
access to these details.
Create a sub struct in the device context which keeps those parameters
which are related to sample memory interpretation. Which also obsoletes
the 'state' struct and only leaves the 'state' enum as a remainder.
Use the "samples per event" condition instead of the samplerate when
extracting a number of samples from an event's storage. Rename the
de-interleaving routines to better reflect their purpose.
Mechanically adjust the add_trigger_function() routine to address nits,
attempt to improve maintainability.
Raise awareness of the fact that strict binary arithmetics is done (bit
operators are used), the strict 0..1 set of values needs to be enforced,
and mere "logical truthness" is not good enough in this spot. Explicitly
check for bit positions instead of "shifting out" the bit of interest
and have the 0/1 value result nearly by coincidence.
Extend comments. Group related instructions and separate them from other
groups. Reduce the scope of the rather generic i, j, tmp named variables
which are just too easy to get wrong.
Rename macros to better reflect which of them check a bit position, and
which span a bit field of given width. Adjust more call sites to use the
macros. This takes tedium out of maintenance as well as review. Has the
minor benefit of somewhat shortening text lines, and eliminating nested
parentheses (or getting perceived as if it would).
Move the acquisition limits related variables into a sub struct within
the device context. Over time they became numerous, and might grow more
in the future.
There are several separate conditions which the driver needs to tell
apart. There is a compile time switch whether trigger support shall be
built in. There is the condition whether acquisition start involved a
user provided trigger spec. And there is the hardware flag whether a
previously configured trigger condition matched and where its position
is.
Only accept user provided trigger specs when trigger support is builtin.
(The get/set/list availability and spec passing is done in applications
outside of the library, we better check just to make sure.) Only setup
the trigger related hardware parameters when a spec was provided. Only
check for trigger positions when the hardware detected a match.
Enable the compile time option which builds trigger support code into
the asix-sigma driver. This is a development hack. Trigger support in
the driver is incomplete and currently not operational.
Address remaining data type nits. Use more appropriate types for sizes
and counters and indices, as well as for booleans.
Prefer more verbose variable names in a few spots to avoid the rather
generic 'i' symbol, especially in complex code paths with deeply nested
flow control or with long distances between declaration and use. Re-use
an existing buffer in the acquisition start for command sequences which
setup trigger in/out as well as clock parameters.
Introduce some variables which may seem unnecessary. But these are
useful for research during maintenance.
This is a mechanical adjustment, behaviour does not change.
Introduce the required infrastructure to store successfully applied
configuration data in hardware registers. This lets the probe phase of
the next sigrok session pick up where the previous session left. Which
improves usability, and increases performance by eliminating delays in
the acquisition start, by not repeating unnecessary firmware uploads.
The vendor documentation suggests there would be FPGA registers that are
available for application use ("plugin configuration"). Unfortunately
experiments show that registers beyond address 0x0f don't hold the data
which was written to them. As do unused registers in the first page. So
the desirable feature is not operational in this implementation. There
could be different netlist versions which I'm not aware of, or there
could be flaws in this driver implementation. This needs more attention.
Stop assuming that C language variables whould have a specific memory
layout that applications could rely on. Use normal data types in higher
abstraction layers, drop non-portable bit fields. Use existing macros
for the creation of bit masks of a given width.
When application code used the common SW limits API, the call sequence
of init() then set() then check() already kept expiring, which is rather
unexpected. The timeout period should only start when start() is called,
check() should not signal expiration before the start() call.
The specific use case is the combination of an msecs timeout and capture
ratio when triggers are used. The post-trigger period only starts when
the trigger match was seen, even though its length is already known when
the acquisition starts. It's desirable to run the start() call for the
post-trigger timeout late, and not terminate the acquisition before the
trigger match.
The previous implementation considered both the UART bitrate and the
frame format mandatory, users had to specify "/8n1" as well just to
change the bitrate.
This commit makes the frame format optional, and defaults to 8n1 which
is so popular these days. When specified, the frame format still needs
to preceed the other optional flow and handshake flags, for maximum
backwards compatibility, and equal robustness in the process of parsing
serialcomm= specs.
Unfortunately device drivers cannot specify their preferred or default
UART frame format. Which means that users still need to provide these
when a device does not use 8n1. This is not a regression, the previous
implementation always needed the frame format spec.
Eliminate doubt from a comment on ASIX SIGMA's channel names which was
introduced in commit d261dbbfcc. Publicly available documentation does
agree their names start at "1" and go up to "16".
The 50MHz netlist supports the use of an external clock. Any of the 16
channels can use any of its edges to have another sample taken from all
the other pins. It's nice that the hardware does track timestamps, which
results in an exact reproduction of the input signals' timing with 20ns
resolution, although the clock is externally provided and need not have
a fixed rate.
Rephrase more parts of sigma_build_basic_trigger() to closer match the
vendor documentation. Use the M3Q name. Be explicit about "parameters"
setup (even if that means to assign zero values, comments help there).
Using three BE16 items for the parameters improves readability.
Rephrase the sigma_build_basic_trigger() and build_lut_entry() routines
to hopefully improve readability. Avoid the use of short and generic
identifiers which are just too easy to confuse with each other and the
1 literal and negation operator in deeply nested loops and complex
expressions that span several text lines. Reduce indentation where
appropriate. Concentrate initialization and use of variables such that
reviewers need less context for verification.
This is a purely mechanical change, the function of triggers remains
untested for now. Setting "selres" in that spot is suspicious, too.
Rephrase the sigma_write_trigger_lut() routine to work on "a higher
level" of abstraction. Avoid short and most of all generic variable
names. Use identifiers that are closer to the vendor documentation.
Reduce the probability of errors during maintenance, and also increase
readability. Replace open coded nibble extraction and bit positions by
accessor helpers and symbolic identifiers. Adjust existing math where it
did not match the vendor documentation. Always communicate 8bit register
addresses, don't assume that application use remains within a specific
"page". Provide more FPGA register access primitives so that call sites
need not re-invent FPGA command sequence construction. Remove remaining
open coded endianess conversion in DRAM access.
The 100/200MHz supporting FPGA netlists differ in their register set
from 50MHz netlists. Adjust the parameter download at acquisition start.
Raise awareness of the "TriggerSelect" and "TriggerSelect2" difference
(the former only exists in 50MHz netlists, the latter's meaning differs
between firmware variants). "ClockSelect" semantics also differs between
netlists. Stop sending four bytes to a register that is just one byte
deep, channel selection happened to work by mere coincidence.
Eliminate a few more magic numbers, unobfuscate respective code paths.
Though some questions remain (trigger related, not a blocker for now,
needs to get addressed later).
Make the list of supported samplerates an internal detail of the
protocol.c source file. Have the api.c source file retrieve the list
as well as the currently configured value by means of query routines.
Ideally the current rate could get retrieved from hardware at runtime.
A future driver implementation could do that. This version sticks with
the lowest supported rate, as in the previous version.
Sort "semi public" routines and "global data" of the asix-sigma driver
in the protocol.h header file by their use. Add comments. This improves
maintenance of the driver source.
Move all of the FTDI connection handling from api.c to protocol.c, and
prepare "forced" and "optional" open/close. This allows future driver
code to gracefully handle situations where FPGA registers need to get
accessed, while the caller may be inside or outside the "opened" period
of the session. This is motivated by automatic netlist type and sample
rate detection, to avoid the cost of repeated firmware uploads.
Detect more error conditions, and unbreak those code paths where wrong
data was forwarded. It's essential to tell the USB communication layer,
sigrok API error codes, and glib mainloop receive callbacks apart. Since
the compiler won't notice, maintainers have to be extra careful.
Rephrase diagnostics messages. The debug and spew levels are intended
for developers, but the error/warn/info levels will get presented to
users, should read more fluently and speak from the application's POV.
Allow long text lines in source code, to not break string literals which
users will report and developers need to search for (this matches Linux
kernel coding style).
This commit also combines the retrieval of sample memory fill level,
trigger position, and status flags. Since these values span an adjacent
set of FPGA registers. Which reduces USB communication overhead, and
simplifies error handling. The helper routine considers the retrieval
of each of these values as optional from the caller's perspective, to
simplify other use cases (mode check during acquisition, before sample
download after acquisition has stopped).
INIT pin sensing after PROG pin pulsing was reworked, to handle the
technicalities of the FTDI chip and its USB communication and the FTDI
library which is an external dependency of this device driver. Captures
of USB traffic suggest that pin state is communicated at arbitrary times.
Address minor style nits to improve readability and simplify review. The
sizeof() expressions need not duplicate data type details. Concentrate
the assignment to, update of, and evaluation of variables in closer
proximity to reduce potential for errors during maintenance. Separate
the gathering of input data and the check for their availability from
each other, to simplify expressions and better reflect the logic's flow.
Further "flatten" the DRAM layout's declaration for sample data. Declare
timestamps and sample data as uint16_t, keep accessing them via endianess
aware conversion routines. Accessing a larger integer in smaller quantities
is perfectly fine, the inverse direction would be problematic.
Keep application data in its logical presentation in C language struct
fields. Explicitly convert to raw byte streams by means of endianess
aware conversion helpers. Don't assume a specific memory layout for
C language variables any longer. This improves portability, and
reliability of hardware access across compiler versions and build
configurations.
This change also unobfuscates the "disabled channels" arithmetics in
the sample rate dependent logic. Passes read-only pointers to write
routines. Improves buffer size checks. Reduces local buffer size for
DRAM reads. Rewords comments on "decrement then subtract 64" during
trigger/stop position gathering. Unobfuscates access to sample data
after download (timestamps, and values). Covers a few more occurances
of magic numbers for memory organization.
Prefer masks over shift counts for hardware register bit fields, to
improve consistency of the declaration block and code instructions.
Improve maintenability of the LA mode initiation after FPGA netlist
configuration (better match written data and read-back expectation,
eliminate magic literals that are hidden in nibbles).
Move the 'devc' parameter to the front in routine signatures for the
remaining locations which were not adjusted yet. Reduce indentation of
continuation lines, especially in long routine signatures. Try to not
break string literals in diagnostics messages, rephrase some of the
messages. Massage complex formulae for the same reason.
Whitespace changes a lot, word positions move on text lines. See a
corresponding whitespace ignoring and/or word diff for the essence of
the change.
The driver got extended in a previous commit to accept any hardware
supported samplerate in the setter API, although the list call does
suggest a discrete set of rates (a subset of the hardware capabilities).
Update a comment to catch up with the implementation.
Drop the 250kHz item, it's too close to 200kHz. Add a 2MHz item to
achieve a more consistent 1/2/5 sequence in each decade. Unfortunately
50MHz and an integer divider will never result in 20MHz, that's why
25MHz is an exception to this rule (has been before, just "stands out
more perceivably" in this adjusted sequence).
Running several firmware uploads in quick repetition sometimes failed.
It's essential to stop the active netlist from preventing the FPGA's
getting reconfigured (FTDI to FPGA pins are so few, and shared). Delays
in a single iteration of the initiation sequence improves reliability.
Retries of the sequence are belt and suspenders on top of that.
Before the change, failure to configure was roughly one in ten. After
the change, several thousand reconfigurations passed without failure.
Use symbolic identifiers to select firmware images, which eliminates
magic 0/1/2 position numbers in the list of files, improves readability
and also improves robustness. Move 'devc' to 'ctx' and before other
arguments in routine signatures while we are here.
FPGA configuration (netlist upload) of ASIX SIGMA devices is rather
special a phase, and deserves its own state in the device context's
"state" tracking. Not only is the logic analyzer not available during
this period, the FTDI cable is also put into bitbanging mode instead
of regular data communication in FIFO mode, and netlist configuration
takes a considerable amount of time (tenths of a second).
Use common support for SW limits, and untangle the formerly convoluted
logic for sample count or time limits. Accept user provided samplerate
values when the hardware supports them, also those which are not listed.
The previous implementation mapped sample count limits to timeout specs
which depend on the samplerate. The order of applications' calls into
the config set routines is unspecified, the use of one common storage
space led to an arbitrary resulting value for the msecs limit, and loss
of user specified values for read-back.
Separate the input which was specified by applications, from limits
which were derived from this input and determine the acquisition phase's
duration, from sample count limits which apply to sample data download
and session feed submission after the acquisition finished. This allows
to configure the values in any order, to read back previously configured
values, and to run arbitrary numbers of acquisition and download cycles
without losing input specs.
This commit also concentrates all the limits related computation in a
single location at the start of the acquisition. Moves the submission
buffer's count limit container to the device context where the other
limits are kept as well. Renames the samplerate variable, and drops an
aggressive check for supported rates (now uses hardware constraints as
the only condition). Removes an unused variable in the device context.
Introduce a 4MiB session feed submission buffer in the device context.
This reduces the number of API calls and improves performance of srzip
archive creation.
This change also eliminates complex logic which manipulates a previously
created buffer's length and data position, to split the queued data when
a trigger position was involed. The changed implementation results in a
data flow from sample memory to the session feed which feels more natural
during review, and better lends itself to future trigger support code.
Use common SW limits support for the optional sample count limit. Move
'sdi' and 'devc' parameters to the front to match conventions. Reduce
indentation in routine signatures while we are here.
This implementation is prepared to handle trigger positions, but for now
disables the specific logic which checks for trigger condition matches
to improve the trigger marker's resolution. This will get re-enabled in
a later commit.
Add more symbolic identifiers, and rename some of the existing names for
access to SIGMA sample memory. This eliminates magic numbers and reduces
redundancy and potential for errors during maintenance.
This commit also concentrates DRAM layout related declarations in the
header file in a single location, which previously were scattered, and
separated registers from their respective bit fields.
Extend comments on the difference of events versus sample data.
Move the FPGA commands (which can access registers, and sample memory)
declarations before the register layout declaration. Which then no
longer separates the registers declarations from their bit fields.
Update comments on the register set while we are here.
Eliminate a few magic numbers in FPGA commands, use symbolic identifiers
for automatic register address increments, and DRAM access bank selects.
Improve grouping of related declarations in the header file.
Slightly rephrase and comment on the FPGA configuration of the ASIX
SIGMA logic analyzer. Use symbolic pin names to eliminate magic numbers.
Concentrate FPGA related comments in a single spot, tell the Xilinx FPGA
from FTDI cable (uses bitbang mode for slave serial configuration).
This fixes typos in the PROG pulse and INIT check (tests D5 and comments
on D6). Also removes the most probably undesired 100s timeout in the
worst case (100M us, 10K iterations times 10ms delay). Obsoletes labels
for error paths. Drops a few empty lines to keep related instruction
blocks together. Includes other style nits.
Stick with the FTDI library for data acquisition, and most of all for
firmware upload (bitbang is needed during FPGA configuration). Removing
this dependency is more complex, and needs to get addressed later.
Re-use common USB support during scan before open, which also allows to
select devices if several of them are connected. Either of "conn=vid.pid"
or "conn=bus.addr" formats are supported and were tested.
This implementation detects and displays SIGMA and SIGMA2 devices. Though
their function is identical, users may want to see the respective device
name. Optionally detect OMEGA devices, too (compile time option, off by
default), though they currently are not supported beyond detection. They
just show up during scans for ASIX logic analyzers, and users may want to
have them listed, too, for awareness.
This implementation also improves robustness when devices get disconnected
between scan and use. The open and close routines now always create the
FTDI contexts after the code has moved out of the scan phase, where common
USB support code is used.
This resolves bug #841.
Eliminate an unnecessary magic number for the maximum filename length of
SIGMA netlists. Use a more compact source code phrase to "unclutter" the
list of filenames and their features/purpose. Move the filesize limit to
the list of files to simplify future maintenance.
Introduce a text to number conversion routine which is more general than
sr_atol() is. It accepts non-decimal numbers, with optional caller given
or automatic base, including 0b for binary. It is not as strict and can
return the position after the number, so that callers can optionally
support suffix notations (units, or scale factors, or multiple separated
numbers in the same text string).
Cover the recently introduced inline routines which back the preprocessor
macros for endianess conversion. Add test sequences for read and write
routines for different data types of different sizes, different endianess
formats and signedness, and include those routines which increment the
read/write position.
Address style, robustness, and usability nits in the common endianess
conversion helpers in the libsigrok-internal.h header file. Rephrase
preprocessor macros as static inline C language functions to eliminate
side effects, and improve data type safety. Provide macros under the
previous names for backwards compatibility, so that call sites can
migrate to the routines at their discretion (or not at all).
Performance is not affected. Inline routines are identically accessible
to compiler optimizers as preprocessor macros with their text expansion
are. Resulting machine code should be the same.
Introduce variants which also increment the read or write position in
the byte stream after data transfer. This reduces more redundancy at
call sites.
Introduce a new tests/conv.c source file which exercises the endianess
conversion macros. It's assumed that some use cases may break their
operation, fortunately these edge cases were not seen before, or the
unreliable operation went unnoticed. This test raises awareness of the
implementation's constraints.
This is a start, the test sequence will benefit from adding some more
cases to increase coverage.
The UT32x driver requires a user spec for the connection. The device
cannot get identified, that's why successful open/close for the port
will suffice. Lack of an input spec as well as failure in the early
scan phase will terminate the scan routine early.
When we reach the end of the scan which creates the device instance
and registers it with the list of found devices, the port already
is closed and the list of devices will never be empty. Remove the
redundant close call and the dead branch which frees the serial port.
src/hardware/siglent-sds/protocol.c: In function 'siglent_sds_get_digital':
src/hardware/siglent-sds/protocol.c:382:35: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (data_low_channels->len <= samples_index) {
^
src/hardware/siglent-sds/protocol.c:391:36: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (data_high_channels->len <= samples_index) {
^
src/hardware/siglent-sds/protocol.c:417:32: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (long index = 0; index < tmp_samplebuf->len; index++) {
^
In file included from src/hardware/siglent-sds/protocol.c:37:0:
src/hardware/siglent-sds/protocol.c: In function 'siglent_sds_receive':
src/hardware/siglent-sds/protocol.h:28:20: warning: format '%li' expects argument of type 'long int', but argument 3 has type 'uint64_t {aka long long unsigned int}' [-Wformat=]
#define LOG_PREFIX "siglent-sds"
^
./src/libsigrok-internal.h:815:41: note: in expansion of macro 'LOG_PREFIX'
#define sr_dbg(...) sr_log(SR_LOG_DBG, LOG_PREFIX ": " __VA_ARGS__)
^
src/hardware/siglent-sds/protocol.c:564:6: note: in expansion of macro 'sr_dbg'
sr_dbg("Requesting: %li bytes.", devc->num_samples - devc->num_block_bytes);
^
src/hardware/siglent-sds/protocol.c: In function 'siglent_sds_get_dev_cfg_horizontal':
src/hardware/siglent-sds/protocol.h:28:20: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'uint64_t {aka long long unsigned int}' [-Wformat=]
#define LOG_PREFIX "siglent-sds"
^
./src/libsigrok-internal.h:815:41: note: in expansion of macro 'LOG_PREFIX'
#define sr_dbg(...) sr_log(SR_LOG_DBG, LOG_PREFIX ": " __VA_ARGS__)
^
src/hardware/siglent-sds/protocol.c:933:2: note: in expansion of macro 'sr_dbg'
sr_dbg("Current memory depth: %lu.", devc->memory_depth_analog);
^
There are cases where the connect() call returns EBUSY when trying to
connect to a device. This has been observed when sampling an RDTech
UM24C. In this case, scanning the device works fine. However, when
sampling the device, Sigrok first scans the device, then closes the
connection and re-opens it to sample the device. If the close/open
calls happen in close successions, the Bluetooth stack sometimes
returns EBUSY.
Work around this issue by retrying if the connect() returns EBUSY.
Signed-off-by: Andreas Sandberg <andreas@sandberg.pp.se>
Since the device should be closed after the scan, close it in sr_modbus_scan.
Alternatively, every single driver could close the device after calling
sr_modbus_scan. This causes duplicated code, is prone to forgetting it and it
wasn't the calling driver who opened the device in the first place.
This change unbreaks maynuo-m97 and rdtech-dps.
Changing triggers (e.g. from low to high) would sometimes cause the
acquisition to seemingly "hang" due to missing variable initializations
(in reality the device would wait for incorrect triggers and/or on
incorrect channels).
This fixes bug #1535.
Prefer the common conversion helper for little endian 16bit signed data.
The previous local implementation only worked for positive values, and
yielded incorrect results for negative temperatures.
This fixes bug #1463.
Including the `functional` header is necessary in order to use `std::function` in the definition of `LogCallbackFunction` when compiling with gcc 7.3.0.
The Ruby bindings currently don't build (at least with Ruby 2.7
and/or SWIG 4.x). Disable them as a temporary workaround until we
have a more permanent fix.
src/resource.c:414: warning: unbalanced grouping commands
conversion.c:81: warning: argument 'lo_thr' from the argument list of sr_a2l_schmitt_trigger has multiple @param documentation sections
src/analog.c:611: warning: return value 'SR_ERR_ARG' of sr_rational_div has multiple documentation sections
src/device.c:205: warning: explicit link request to 'TRUE' could not be resolved
src/device.c:205: warning: explicit link request to 'FALSE' could not be resolved
src/device.c:231: warning: explicit link request to 'TRUE' could not be resolved
src/device.c:231: warning: explicit link request to 'FALSE' could not be resolved
src/serial.c:246: warning: explicit link request to 'NULL' could not be resolved
src/strutil.c:602: warning: explicit link request to 'NULL' could not be resolved
src/device.c:94: warning: unable to resolve reference to 'sr_channel_free()' for \ref command
src/strutil.c:597: warning: unable to resolve reference to 'sr_hexdump_free()' for \ref command
src/strutil.c:622: warning: unable to resolve reference to 'sr_hexdump_new()' for \ref command
src/device.c:430: warning: The following parameters of sr_dev_inst_channel_add(struct sr_dev_inst *sdi, int index, int type, const char *name) are not documented: parameter 'sdi'
src/session.c:163: warning: The following parameters of fd_source_new(struct sr_session *session, void *key, gintptr fd, int events, int timeout_ms) are not documented: parameter 'events'
Since we've now seen lots of devices in the wild that come with the
"HCS-" prefix in the ID, it's probably safe to assume all of them
could have it.
This fixes bug #1530.
The previous implementation got stuck in an infinite loop when data
acquisition started, but the device got disconnected before the data
acquisition terminates. An implementation detail ignored communication
errors, and never saw the expected condition that was required to
continue in the sample download sequence. Unbreak that code path.
Even though the devices/websites/manuals usually say 0..30V, the
hardware actually accepts up to 31V, both via serial as well as by
simply rotating the knob on the device (and our driver already
reflects that).
The same is true for current, it's usually 0..5A as per docs, but many
(probably all) devices accept 5.1A via serial and knob.
Thus, set the max current of all devices to 5.1A (or 3.1A for 3A
devices). We're assuming they all have this property, and we've seen
this in practice on at least three different versions of the device.
On a recently acquired Korad KA3005P power supply, the ID supplied by the
device is not known by libsigrok.
$ sigrok-cli --driver=korad-kaxxxxp:conn=/dev/ttyACM0 --scan
sr: korad-kaxxxxp: Unknown model ID 'KORAD KA3005P V4.2' detected, aborting.
This fixes bug #1522.
Thanks to bitaround@gmail.com for the amperage fix.
The DMMs report as an event to which mode the user switched (by turning the
rotary switch): "*0", "*1", etc.
Most other DMMs have few modes, but the U127x DMMs have up to 11 different
modes (i.e., "*10" is a valid event).
The @brief keyword is not needed since JAVADOC_AUTOBRIEF is enabled in the
Doxygen configuration. Remove a remaining "DIAG" prefix in a debug
message, the output already is filtered according to the log level, and
prefixed by the module name.
Don't clobber the user provided samplerate (specified by input module
options). This allows to re-determine the samplerate from a potentially
changed file on disk upon reload.
The list of previously created channels is kept across file reloads. We
also need to keep (or re-create) the list of channels that are used for
datafeed submission of analog data.
Release more allocated resources in the .cleanup() routine, and do reset
internal state such that a .reset() thus .cleanup() then .receive() call
sequence will work. This code path is taken for re-import of files (see
bug #1241, CSV was affected).
Slightly unobfuscate the "end of current input chunk" marker in the data
processing loop. Make the variable's identifier reflect that it's not a
temporary, but instead something worth keeping around until needed again.
Unbreak the calculation of line numbers in those situations where input
chunks (including previously accumulated unprocessed data) happens to
start with a line termination. This covers input files which start with
empty lines, as well as environments with mutli-byte line termination
sequences (CR/LF) and arbitrary distribution of bytes across chunks.
This fixes bug #968.
Accept when there is no line termination in the current input chunk. We
cannot assume that calling applications always provide file content in
large enough chunks to span complete lines. And any arbitrary chunk size
which applications happen to use can get exceeded by input files (e.g.
for generated files with wide data or long comments).
Mention the required synchronization of default option values and format
match logic in a prominent location where options are discussed.
Update the TODO list for the CSV input module. Mixed signal handling got
fixed by rearranging channel creation. Samplerate can get determined
from timestamp columns already. The double data type for analog data
remains.
The previous implementation incompletely handled arbitrary data type
oders in mixed signal input files. Rearrange the logic such that all
format specs get parsed first, then all channel creation details get
determined, then all channels get created. It appears to be essential
that all logic channels get created first, resulting in index numbers
starting at 0 and addressing the correct position in bitfields. The
analog channels get created after all logic channels exist. Adjacent
number ranges for channel types also results in more readable logic in
other locations.
This was tested with -I csv:column_formats=t,2a,l,a,x4,a,-,b3 example
data, and works as expected.
Implement .format_match() support in the CSV input module. Simple
multi-column files will automatically load without an "-I csv" spec.
Non-default option values still do require the module selection before
options can get passed to the module.
Try to balance a compact format and completeness/accuracy of content for
builtin help texts for the CSV input module's options. Assume a technical
audience (this is signal analysis software after all).
Rename a few internal identifiers which help organize the list of options
and their help texts. Too short names became obscure.
Accept 't' format specs for timestamp columns. Automatically derive the
samplerate from input data when timestamps are available and the user
did not provide a rate. Stick with a simple approach for robustness
since automatic detection is easy to override when it fails. This
feature is mostly about convenience.
The previous implementation open coded type checks by comparing an enum
value against specific constants. Which was especially ugly since there
are multiple types which all are logic, and future column types neither
get ignored nor have channels associated with them.
Improve readability and robustness by adding helpers which check classes
(ignore, logic, analog) instead of the multitude of -/x/o/b|l/a variants
within the classes.
Also comment on the order of channel creation, and how to improve it.
Expand the developer comment that's inline in the source file. There is
enough room to explain things. Try to come up with a "one-line" help text
that is precise yet compact, and does inform the user of available format
choices including modifiers. Chances are that longer descriptions start
reducing the usefulness of the help or the visibility of options when
users are in a hurry. Those who care can access the manual.
Mark more options as obsolete, and mention more default values in the
builtin help text. Also tweak a comment on getting channel names from
header lines.
Support for mixed signal CSV input data is desirable and should be
possible. The current implementation just happens to not fully cope with
arbitrary mixes of data types in columns yet. Add a quick workaround,
but also a TODO item to properly address the topic later.
Extend the CSV input module which was strictly limited to logic data so
far. Add support for analog data types. Implement the 'a' column format,
and feed analog data to the session bus.
This implementation feeds data of individual analog channels to the
session bus in separate packets each. This approach was found to work
most reliably, not all recipients support the submission of multiple
samples for multiple channels in a single packet.
A fixed 'digits' value is used. This needs to get addressed later.
Local experiments suggest that the 'double' data type for analog data
can result in erroneous visual presentation (observed with sigrok-cli).
Use 'float' for now, until the issue is understood and got fixed.
Support for double is prepared internally and is easily enabled.
Address several minor nits. Eliminate unneeded variables. Update text to
number conversion comments including wildcard handling. Remove empty
lines in init() which used to spill out a set of lines which all do the
same thing (evaluate a set of options) and shall belong together.
Move the creation of logic channels to the location where formats fields
get iterated, and column processing details get derived. This reduces a
lot of redundancy, and simplifies the addition of more data formats.
Update the list of TODO items at the top of the CSV input module's
source. Text line handling (counting line numbers) got fixed. Adding
support for analog channels was prepared, as are timestamp columns.
Rename the CSV input module's option keywords. To better reflect their
purpose, and for consistency across the rather complex set of options
and how they interact. Rearrange the list of options (not that the order
matters from the outside, but it's good to have during maintenance).
Update builtin help texts which will show up in applications, as well as
the source code comments which discuss these options in greater detail.
Would be nice to have a "general" help text for input modules which is
not tied to one single option, to provide an overview or use examples.
Arrange the option keys, short and long help texts such that the source
better reflects the applications' screen layout. To better support
future maintenance, again.
Consistently separate multi-work keywords for improved readability.
Prefer underscores over dashes for consistency with common keys in
shared infrastructure in other project sources (device options, MQ
items, etc).
Extend the "column-formats" option support in the CSV input module to
also support wildcards and automatic channel count detection. Move the
format string interpretation to the location where the first data line
or the optional header line are seen. Map the simple options (single
column number and channel count, or first column number and optional
channel count) to a format string, to unify internal code paths. Remove
code paths for the previous specific yet limited scenarios.
Rephrase the condition which keeps executing the "initial receive"
phase. The text line termination sequence gets derived from the first
complete text line, but other essential information is only gathered
later, potentially after skipping a large (user specified) amount of
input data. Keep checking for this essential setup data until data or
the header actually were seen, before regular processing of input data
starts.
Extend the CSV input module, introduce support for the "column-formats="
option. This syntax can express the previous single- and multi-column
semantics, as well as any arbitrary order of to-get-ignored, and single-
and multi-bit columns in several formats.
The previous "simple" keywords for single and multi column modes still
are in place, it's yet to get determined whether to axe them. Depends on
whether users can handle the format strings for these simple cases.
The previous implementation allowed CSV input files to use any line
termination in either CR only, LF only, or CR/LF format. The first EOL
was searched for and was recorded, but then was not used. Instead any of
CR or LF were considered a line termination. "Raw data processing" still
was correct, but line numbers in diagnostics were way off, and optional
features like skipping first N lines were not effective. Fix that.
Source code inspection suggests the "startline" feature did not work at
all. The user provided number was used in the initial optional search
for the header line (to get signal names) or auto-determination of the
number of columns. But then was not used when the file actually got
processed.
Reduce "state" in the CSV input module's context. Stick with variables
that are local to routines when knowledge of details need not be global.
Really base the processing of a column's input text on the column's
processing information which was gathered in the setup phase.
Rename few identifiers, to explicitly refer to logic channels (the only
currently supported data type of the CSV input module). Cease feeding
logic data to the session bus when there are no logic channels at all
(currently not really an option). Prepare for simpler dispatching of
parse routines should more data types get added in a future version.
Reduce some "clutter" (overly fragmented stuff that should go together
since it forms logical groups and is not really standalone). Address a
few more minor style nits (sizeof() redundancy, "seemingly inverse"
string comparison phrases).
Improve the code paths which determine logic channels' names from an
optional CSV file header line. Strip optional quotes from the column's
input text (re-use a SCPI helper routine for that). Also use the channel
name for multi-bit fields, append [0] etc suffixes in that case. Comment
on the manipulation of input data, which is acceptable since that very
data won't get processed another time in another code path.
Rephrase the CSV input module's implementation such that generic support
to "process a column" becomes available. All columns of an input file's
text line get inspected, a column can either get ignored, or converted
to logic data. A future version can then remove the current limitations
of single- and multi-column modes (either one single multi-bit cell, or
multiple single-bit cells which must be adjacent).
Combine the bin/oct/hex parse routines into one routine which handles up
to four bits per input number digit with common logic. Availability of
more data than channels (according to user specs) is not fatal.
Drop the counter intuitive "first-channel" option, use "first-column"
instead. Warn when comment leader and column separator are identical
(was silent before, may be unexpected). Extend diagnostics and address
minor readability nits, update comments. Rephrase logic channel name
assignment.
Use simple scalar options to derive generic processing details: Either
'single-column' and 'numchannels' are required, with an optional
'format' spec (resulting in single-column mode). Or 'first-column' with
an optional 'numchannels' (multi-column mode with fixed format, using
all available columns by default). The default is multi-column mode with
one logic channel per column and spanning all columns on a text line.
Don't clobber the value of the user provided 'header' option. Use a
separate flag to track whether the header line was seen before, or
needs to get skipped when it passes by.
Move the communication of the samplerate meta packet to the very spot
where logic sample data gets sent. This allows to optionally determine
late the samplerate, potentially from input data instead of user specs.
Move the helper routines which arrange for the data feed to an earlier
spot, so that references resolve without forward declarations. Rename
routines to reflect that they deal with logic data.
Slightly unobfuscate column text to logic data conversion, and reduce
redundancy. Move sample data preset to a central location.
Rephrase error messages, provide stronger hints as to why the input text
for a conversion was considered invalid.
The previous implementation assumed that in multi-column mode each cell
communicates exactly one bit of input (a logic channel). But only the
first character got tested. Tighten the check, to cover the whole input
text. This rejects fully invalid input, as well as increases robustness
since multi-bit input like "100" was mistaken as a value of 1 before.
Add documentation to the bin/hex/oct text parse routines, and move the
bin/hex/oct dispatcher to the location where its invoked routines are.
Stick with a TODO comment for parse_line() to reduce the diff size.
The parse_line() routine is rather complex, optionally accepts an upper
limit for the number of columns, but unconditionally assumes a first one
and drops preceeding fields. The rather generic n and k identifiers are
not helpful.
Use the 'seen' and 'taken' names instead which better reflect what's
actually happening. Remove empty lines which used to tear apart groups
of instructions which are strictly related. This organization neither
was helpful during maintenance.
Accept when comments are indented, trim the whitespace from text lines
after stripping off the comment. This avoids the processing of lines
which actually are empty, and improves robustness (avoids errors for a
non-fatal situation). Also results in more appropriate diagnostics at
higher log levels.
The CSV input module has grown so many options, that counting them by
hand became tedious and error prone. Eliminate the magic numbers in the
associated code paths.
This also has the side effect that the set is easy to re-order just by
adjusting the enum, no other code is affected. Help text and default
values is much easier to verify and adjust with the symbolic references.
[ see 'git diff --word-diff' for the essence of the change ]
Use size_t for things that get counted: column indices, channel numbers
(line numbers already used size_t). De-anonymize an enum to avoid 'int'
where it gets referenced. Adjust printf(3) format strings. Get unsigned
values from option lookups (stick with 32bits, should be acceptable for
spreadsheet columns and channel counts).
Address other minor nits while we are here: Also terminate the last item
in an enum declaration. Add a doxygen comment for parse_line(). Rename a
parameter to achieve tabular doc text layout.
Rephrase the #include statements in the CSV input module. "config" is
not a system header but is provided by the application source code.
Separate the config and system and application groups (their order is
essential). Alpha-sort the files within their group for simplified
maintenance.
Do for the CSV input module what commit 08f8421a9e did for VCD. Check
the channel list for consistency across re-imports of the same file.
This addresses the CSV part of bug #1241.
The cleanup() routine gets invoked upon shutdown, as well as before
re-importing another file. The cleanup() routine must not release
resources which get allocated in the init() routine, as the init()
routine won't run again in the module's lifetime. The cleanup() routine
must void those context fields which get evaluated in the next receive()
calls.
The previous implementation inspected the input stream's samplerate, and
simply used the next 1kHz/1MHz/1GHz timescale for VCD export. Re-import
of the exported file might suffer from rather high an overhead, where
users might have to downsample the input stream. Also exported data
might use an "odd" timescale which doesn't represent the input stream's
timing well.
Rephrase the samplerate to VCD timescale conversion such that the lowest
frequency is used which satisfies the file format's constraints as well
as provides high enough a resolution to communicate the input stream's
timing with minimal loss. Do limit this scaling support to at most three
orders above the input samplerate, to most appropriately cope with odd
rates.
As a byproduct the rephrased implementation transparently supports rates
above 1GHz. Input streams with no samplerate now result in 1s timescale
instead of the 1ms timescale of the previous implementation.
The 'period' member of the VCD output module's context is supposed to
hold frequencies that correspond to the timescale used during export.
An 'int' (in combination with VCD's 1/10/100 constraint) thus would
result in a 1GHz limit, use uint64_t instead to support higher rates.
Iterate over the received sample set first, before iterating over the
respective sample's number of channels. This avoids redundant extraction
of sampled bits (which saves only little), but also increases locality
of processed data (though string accumulation still may be expensive).
It also adds the future option of RLE compression during accumulation of
output data, which perfectly matches the WaveDrom syntax for repeated
bit patterns.
Rearrange the order of routines in the wavedrom output module. Keep the
flow of .receive() -> .process_logic() -> .wavedrom_render() in one common
group of routines, which is not disrupted by the .init() and .cleanup()
routines which are kind of boilerplate in the source file. This increases
readability and maintainability.
Adjust brace style, use C language comments, drop camel case. Use size_t
for indices and offsets. Unobfuscate the open/close logic of rendered
output. Allocate zero-filled memory, reduce sizeof() redundancy. Don't
SHOUT in the module's .name property.
[ Changes indentation, see 'git diff -w -b' for review. ]
Add a comment on the logic which skips the upper 64 bytes of a 512 bytes
chunk in the Asix Sigma's sample memory. Move the initial assignment and
the subsequent update from a value which was retrieved from a hardware
register closer together for awareness during maintenance. Pre-setting a
high position value that will never match when the feature is not in use
is very appropriate.
Adjust the sigma_read_pos() routine to handle triggerpos identically to
stoppos. The test condition's intention is to check whether a decrement
of the position ends up in the meta data section of a chunk. The previous
implementation tested whether a pointer to the position variable ended in
0x1ff when decremented -- which is unrelated to the driver's operation.
It's assumed that no harm was done because the trigger feature is
unsupported (see bug #359).
This silences the compiler warning reported in bug #1411.
The handler for fluke 18x and 28x DMMs allocates several data
structures on the stack that are used after they have been freed when
creating a data feed packet.
Restructure the code so that all handlers send their own packets. As a
bonus, this avoid a couple of small heap allocations.
By separating the variables that holds the get and set values, the output
state, OVP and OCP can now be set while the acquisition is running.
Also some variables are named more clearly.
The communication with the rdtech power supplies is not very reliable,
especially during the start. Because of that, the driver tries to read the
modbus registers up to three times.
Nevertheless there is the chance, that the communication fails.
Introduce quirks support for devices which provide incomplete metadata.
Add conservative logic to unbreak the Logic Shrimp. Amend previously
received information when it was incomplete, but don't interfere if a
future firmware version fixes the issue.
Without this change, the device gets detected but "has zero channels"
and would be unusable. Because when a device provides metadata, these
details are used exclusively, no fallbacks apply.
There is no reason to close the entire device in acquisition_stop and
this actually breaks pulseview on serial devices using this callback
when running multiple acquisition cycles
This fixes bug #1271.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
The Mooshimeter driver uses mem*() and str*() library calls. Include the
<string.h> header file to silence compiler warnings.
...
./src/hardware/mooshimeter-dmm/protocol.c: In function 'lookup_tree_path':
./src/hardware/mooshimeter-dmm/protocol.c:275:3: warning: implicit declaration of function 'strchr' [-Wimplicit-function-declaration]
end = strchr(path, ':');
^
./src/hardware/mooshimeter-dmm/protocol.c:275:9: warning: incompatible implicit declaration of built-in function 'strchr' [enabled by default]
end = strchr(path, ':');
^
...
Even working BLE devices won't immediately succeed in the first call to
connect(2), which is why the "in progress" phase was added. But absent
peers made the previous implementation try forever, getting stuck in the
sr_bt_connect_ble() call.
Try to balance these two constraints. Do terminate BLE connect attempts
after a generous timeout. When this 20s period passed, there probably is
a configuration error or unresponsive peer. Yet the timeout needs to be
in this ballpark to not erroneously fail for working setups.
This adds support for the Mooshim Engineering BLE based Mooshimeter.
Because the meter requires raw BLE packets, the driver uses the BLE
layer directly. Since the meter has no physical way of configuring it,
the actual configuration is set entirely with sigrok device options.
When libsigrok is compiled with link-time-optimization, the linker
stumbles over the section named the same as the function. Whether this
is a compiler/linker bug or a coding error is unknown.
Renaming the special section (to the same as already used on OS X) avoids
the problem.
This fixes bug #1416.
Doxygen version 1.8.16 introduced an issue which breaks the compilation
of sigrok's C++ binding (https://github.com/doxygen/doxygen/issues/7190).
Don't set the FILE_PATTERNS variable at all, instead of assigning an
empty value. This resolves bug #1422.
This adds basic support for the Rigol MSO5000 series. It has
the same problems as the DS4000 series: Live capture provides
one digital channel per byte. Buffered memory returns the data
compressed (one byte has 8 digital channels), but the banks are
read separately. It's not possible to read uint16.
Introduce the lcr/vc4080.c source file which implements the parser for
the serial data stream of the Voltcraft 4080 LCR meter. Add the meter to
the list of supported devices in the serial-lcr driver, as well as the
PeakTech 2165 LCR meter which is another compatible device.
This implementation contains a workaround for USB based serial cables
which seem to suffer from incomplete parity handling (observed with the
FT232R based PeakTech cable). Similar approaches were seen in existing
DMM drivers.
This implementation supports the main and secondary displays. The D and Q
"displays" which are communicated in the serial packets appear unreliable
and redundant, users can have the D and Q values shown in the supported
displays.
Commit cb5cd1538f introduced packet request support in the serial-lcr
device driver. Calls were added to the detection of the device's
presence, and the periodic acquisition of measurement data. Add another
call to the device configuration retrieval that follows the presence
detection, without it communication timed out with no data received.
Also slightly raise the timeout for this device configuration gathering
phase. With one second sharp, the VC4080 was detected, but getting its
current configuration kept failing. This device's serial communication
is extra slow (1200 bps) and the packets are rather large (39 bytes).
Which made the stream detect's receive routine stop checking for the
availability of more data while a packet was being received.
Move the initial device probe (LCR packet validity check), the creation
of the device instance after successful probe, and the subsequent packet
inspection after resource allocation out of the scan routine. This shall
improve readability of the serial-lcr driver's probe logic, and reduces
diffs when handling of multiple connections gets added later.
Add a developer comment, the serial-lcr driver needs to handle multiple
connections when the conn= spec is ambiguous (multiple cables of the
same type, with the same VID:PID).
The HID transport for serial communication was rather noisy at log
levels of 4 and above. Now that test coverage was increased and
operation is stable, drop a lot of the excessive and redundant debug
messages in regular code paths.
According to the latest available version of the manual, as
for the RTB2000 and RTM3000 series, the RTA4000 series also
uses a slightly different dialect than other previously
supported models, in particular when it comes to the POD
(logic channel groups) handling.
I do not have such model available for testing therefore, as
for the RTB2000 and RTM3000 support recently introduced, I do
not know whether or not the RTA4000 also understands the
existing dialect. In doubt, the new official dialect is
implemented by this patch.
According to the latest available version of the manual, they
both use a slightly different dialect than currently supported
models, in particular when it comes to the POD (logic channel
groups) handling.
I do not have any of the above models available for testing
therefore I do not know whether or not they also understand
the existing dialect. In doubt, the new official dialect is
implemented by this patch.
Update the oscilloscope state with new settings only after
they have been successfully stored in the device to avoid
an inconsistent state in case of SCPI SET command failure.
The hameg-hmo driver returns an incorrect sample rate: to reproduce this
bug, set the maximum sample rate from the ACQUIRE menu.
This patch fixes the driver so that the correct sample rate is returned.
During the initial configuration phase of the hameg-hmo driver
only send an OPC command if a SCPI command has been previously
sent to the device so that bogus SCPI timeouts are avoided.
The current starting index for the POD name is currently wrong as it is zero.
The official POD numbering starts instead at 1 (see device panel, buttons
and manual), so the current index used for message printing and groups
naming in the driver needs to be incremented by one.
Avoid double memory freeing leading to segmentation fault in when a SCPI
command fails to get a string due conditions such as a timeout or an invalid
command.
When setting the type of slope for the edge trigger function, also set the
trigger type to edge because it is not necessarily configured that way and
therefore such functionality might fail to work properly!
This fixes parts of bug #1328.
Update the Hameg/Rohde&Schwarz HMO driver (hameg-hmo) so that it
is possible to configure the logic threshold for digital signals.
The user can get or set the logic threshold configuration using
the channel group POD0 (and/or POD1 where available), for example:
sigrok-cli --driver hameg-hmo --get logic_threshold -g POD0
sigrok-cli --driver hameg-hmo --config logic_threshold=TTL --set -g POD0
sigrok-cli --driver hameg-hmo --get logic_threshold_custom -g POD0
sigrok-cli --driver hameg-hmo --config logic_threshold_custom=0.7 --set -g POD0
Update the default serial port options for Rohde&Schwarz and
Hameg mixed-signal oscilloscope devices connected through USB.
Also, remove misplaced and unused serial port configuration option.
This patch complements fa3d104f17
in terms of updating the USB PIDs for new devices (HMO series).
This fixes parts of bug #1321.
If no serial port option is specified on the command-line using the
"serialcomm" driver option, but the device is connected through USB
and it requires a known default serial port option, then use it in
order to avoid data corruption or even worse problems.
Note: the easiest way to reproduce data corruption on HMO3000 series
is to start an analog data acquisition (e.g. on channel CH1) after
switching from Ethernet mode to USB VCP mode (HO732 USB/Ethernet interface).
This fixes parts of bug #1321.
Correctly set the length of the buffer used to hold the SCPI response
from the device containing the binary acquisition data.
If a timeout occurs, truncate the buffer and send the partial response
from the device instead of getting stuck on timeouts!
Thanks to Stefan Brüns for reviewing the first version of this patch
and spotting out a serious problem with it.
This fixes bug #1323.
At the moment only the maximum number of frames to be acquired can be
configured for the Hameg/Rohde&Schwarz HMO mixed-signal oscilloscope
series driver (hameg-hmo).
This patch adds support to configure the number of samples to acquire
in both analog and digital (logic) mode.
This patch introduces the support for 16 digital (logic) channels for the
following oscilloscope models: HMO3032, HMO3042, HMO3052 and HMO3522
(previously only 8 digital channels were supported, i.e. only 1 POD).
This patch takes care of removing an invalid product model (HMO2522)
and adds a missing product model (HMO3522) in the hameg-hmo driver,
thus extending the number of supported oscilloscope models.
This fixes bug #1322.
The trigger range/mask "compression" procedure is apparently not
required and breaks triggering on a low line state.
This has been verified to fix the issue on a Hantek 4032L with FPGA
version 0x4303. It is possible that the procedure mentioned above
might be required for other FPGA versions, though that is unknown.
If you experience trigger issues with other FPGA versions, please
contact us for further debugging and testing.
This fixes bug #1402.
The Brymen BM86x supports up to two temperature probes. The dual display
can show individual temperatures of the two probes or differences. The
previous implementation "detected" a value of zero degrees when no probe
was attached and the display showed dash lines. When cycling assignments
of probes to displays, some valid combinations did not result in values
shown by the libsigrok driver.
An implementation detail of the formerly separate brymen-bm86x driver
was lost during recent migration of the dmm/bm86x parser into the
serial-dmm driver. When the meter's temperature function is selected,
it's essential to inspect the primary display's flags and digits, to
determine the secondary display's quantity and unit. Previous versions
never bothered to explicitly check for the "----" digits text, but the
combination of the primary's last digit showing C/F as well as the
binary C/F flags before the value provided hints which the secondary
displays group of digits and flags did not.
This fixes bug #1394.
When the list of all connections gets created which are supported by the
HID serial transport, items contain a "hid/ch9325/raw=/dev/hidraw3" path
and a "1a86:e008" pair of vendor and product IDs.
Separate the VID/PID pair by a period not a colon, so that --list-serial
output immediately becomes usable with "--driver <name>:conn=<spec>"
invocations. Eliminate the necessity to adjust clipboard context by the
user. This improves usability in cases where not a single connection
gets addressed, but a group of connections gets specified by ambiguous
conn= specs.
$ sigrok-cli -d uni-t-ut32x:conn=1a86.e008 --scan
Some meters require the reception of a request before they provide
acquisition data. Add support for the chip driver's .packet_request()
routine, and timeout handling in the serial-lcr driver. This follows
the serial-dmm model.
Allow LCR chip drivers to specify custom printf() formats for their
channel names. Default to "P1" etc in the absence of format specs.
This implementation is similar to serial-dmm.
The EEVBlog 121GW meter support always registers the three-displays
parse routine with the serial-dmm device driver. The single-display
routine need not be public. Adjust the visibility.
Reduce indentation for a continued line in a nearby declaration
while we are here.
Bug #1390 reports that "!desc" is always true (should be: false?). But
the actual problem would be that 'desc' is _not_ NULL when none of the
supported chips' VID:PID matched (FT232H happens to "get found" then,
erroneously).
Add a sentinel to the table of supported chips, such that 'desc' becomes
NULL upon mismatch, and the error path is entered.
The serial-dmm entry for Victor DMMs is able to communicate to either
geniune COM ports (RS232 or USB CDC) or the obfuscating USB HID cables.
The victor-dmm driver became obsolete and was removed. Rename the
serial-dmm entry, remove the no longer needed "-ser" suffix. Suggest a
default connection via the obfuscating USB HID cable, accept user
provided overrides for regular serial cables (same behaviour as before,
connection spec for serial ports keeps being mandatory).
Remove the victor-dmm device driver. Its functionality is contained in
the Victor specific serial-over-HID transport, the FS9922 DMM parser,
and the serial-dmm device driver. The additional implementation became
obsolete.
Introduce a serial transport which undoes the Victor DMM cable's
obfuscation to the DMM chip's original data packet. Which allows to
re-use the existing FS9922 support code, obsoleting the victor-dmm
device driver.
This undoes the essence of commit bf700f679a, which introduced the
default conn= spec. Which improved usability: Users just select the
device and need not specify the connection. But also resulted in the
UT32x thermometer driver's probe to "succeed" as soon as the WCH CH9325
chip was found, no data check was involved in the scan. Unfortunately
this chip is also used in the popular UT-D04 cable, and thus there were
many false positives.
Remove the src/hardware/brymen-bm86x/ hierarchy of source files. Its
functionality has moved to the bm86x packet parser and the serial-dmm
device driver.
Request packets from the Brymen BM86x meter much faster. The previous
implementation in the separate driver used to immediately send another
request when a measurement arrived, with a 10ms granularity in the poll
routine, and a 500ms timeout between requests.
Considering the meter's update rate, stick with the 500ms timeout, but
increase the maximum request rate to 10 per second, with a minimum of 2
per second. This receives measurement data at the meter's capability
(compare DC and AC modes, seems to automatically adjust to the internal
operation, and match the display update rate).
Move Brymen BM86x specific packet parse logic to a new src/dmm/bm86x.c
source file, and register the routines with the serial-dmm driver's list
of supported devices. Which obsoletes the src/hardware/brymen-bm86x/
hierarchy.
This implementation differs from the previous version: The parse routine
gets called multiple times after one DMM packet was received. Values for
the displays get extracted in separate invocations, the received packet
is considered read-only. Unsupported LCD segment combinations for digits
get logged. Low battery gets logged with higher severity -- the validity
of measurement values is uncertain after all. The parse routine uses
longer identifiers. Packet reception uses whichever serial transport is
available (need no longer be strictly USB HID nor libusb based). All
features of the previous implementation are believed to still be present
in this version.
This configuration queries measurement values each 0.5 seconds and
re-sends a not responded to request after 1.5 seconds. Which follows the
combination of the vendor's suggested flow (frequency) and the previous
implementation's timeout (3x 500ms). This implementation does not try to
re-connect to the HID device for each measurement, and neither checks
for the 4.0 seconds timeout (vendor's suggested flow). Local experiments
work without these.
The src/hardware/brymen-bm86x/ source code contains specific support for
the Brymen BM86x devices, and directly depends on the libusb library.
Rename the registered device (append the "-usb" suffix) before adding
BM86x support to the serial-dmm driver.
The Brymen BU-86X infrared adapters are sold with BM869s meters. Raw
streams of data bytes get communicated by means of HID reports with
report number 0 and up to 8 data bytes each. Communication parameters
are fixed and need no configuration.
Some meters which are supported by the serial-dmm driver don't strictly
require the user's COM port specification. When a known (usually bundled,
or even builtin) cable type is used, we can provide a default conn= spec
and thus improve usability. Prepare the DMM_CONN() macro, accept user
overrides.
The 'conn' field in the device context and the CONN values in the
declarations of supported DMM models seemed inappropriate. They specify
the communication parameters (UART frame format and bitrate), not the
connection (port name). Adjust the respective identifiers.
Also rephrase the evaluation logic. Instead of checking for the absence
of user specs and optionally assigning a fallback value, just preset
from defaults and override from user specs when present. This simplifies
the logic (eliminates a check).
Keep the ES51919 chip support in the src/lcr/ directory, and move device
driver specific code to the src/hardware/serial-lcr/ directory. Implement
the same driver layout for LCR meters as is used for DMM devices.
This also addresses a few issues in the serial-lcr driver: Unbreak --get
and --show, do process a few LCR packets after probing the device, to
gather current parameter values. Keep sending meta packets when these
parameters change during acquisition, like the previous implementation
did. Use common code for frame/time limits.
Note that although LCR meters usually operate with AC to classify L/C/R
components, one of the officially supported modes is DC resistance.
Which means that an output frequency of 0 is not just a fallback when
packet parsing fails, it's also a regular value of the freq parameter.
List all supported frequencies including DC in strict numerical order.
Although all currently supported devices use the same ES51919 chip, the
implementation is prepared to support other devices which use different
LCR meter chips as well. The list of known equivalent circuit models and
output frequencies is kept in src/lcr/ chip support. It's assumed that
one LCR packet communicates the data for all channels/displays similar
to the serial-dmm driver implementation.
The serial communication timing parameters during probe get determined
from earlier serial port configuration, which obsoletes the redundant
'baudrate' parameter, and eliminates potential inconsistency between
user specified parameters and builtin default values.
The serial communication timing parameters during probe get determined
from earlier serial port configuration, which obsoletes the redundant
'baudrate' parameter, and eliminates potential inconsistency between
user specified parameters and builtin default values.
The serial_stream_detect() routine needs to estimate the time which is
needed to communicate a given amount of data. Since the serial port got
opened and configured before, the serial communication parameters are
known, and callers need not redundantly specify the bit rate.
The previous implementation provided a raw input stream of RX data from
read() calls to device drivers. This works great with genuine COM ports,
as well as with most setups which involve simple "cable expanders".
Recent additions of alternative transports (serial over HID and BLE)
added more protocol layers to the setup, and some device drivers are
reported to depend on the very framing of these transports: Mooshimeter
cares about individual BLE notification "frames", and the information
cannot get derived from the payload bytes. Some HID based cables which
obscure the DMM chips' serial protocol, or some HID based setups which
the serial layer does not abstract away as "a cable" may suffer from
similar requirements (do some drivers require access to individual HID
reports? Ikalogic? Victor DMM?).
Add support for an optional "RX chunk callback" which takes precedence
over "mere payload byte streams". Instead of returning payload bytes
from read() calls, the serial layer can call an application defined
routine and pass data bytes in the very framing which the physical
transport happens to use.
It's still up to the implementation of the specific transport whether
the callback approach is supported, and whether the wire's framing is
obeyed or whether payload data keeps getting provided as one raw stream.
It's also implementation dependent whether data reception transparently
occurs in background, or whether callers need to periodically "stimulate"
data reception by calling read or check routines which happen to call
back into the caller should RX data become available.
The approach that got implemented here is not universally applicable,
but serves those specific environments that were identified so far.
The CP210x USB to UART bridge is not specific to CEM DT-8852, it's a
generic bridge chip that is also used in other cables and devices. Add
the CP2110 USB HID to UART bridge that is found in UNI-T cables and
devices, and reported to also be used in Voltcraft devices.
WCH CH9325 and SiL CP2110 chips (and other HID cables) won't match the
currently used 'usb' subsystem when the platform registers these as
'hidraw' devices. Adjust the 60-libsigrok.rules SUBSYSTEM condition.
Add more examples of conn= specs for HID and Bluetooth devices to the
section which discusses COM ports. Outline the formal syntax and its
optional fields. Discuss how colons in device addresses interfere with
"-d <drv>:conn=<spec>" environments.
Introduce the serial_bt.c source file which implements the methods of a
serial transport and calls into the platform agnostic src/bt/ support
code.
Implement support for several chips and modules: RFCOMM (BT classic,
tested with HC-05), BLE122 (tested with 121GW), Nordic nRF51, and TI
CC254x (the latter untested). Read support is assumed to be complete,
write support for BLE may be incomplete due to lack of access to
hardware for tests.
Create a src/bt/ subdirectory for source files. Declare a platform
agnostic internal API for Bluetooth communication, and provide an
implementation of that portable API when the BlueZ library is available.
This implementation assumes that HAVE_BLUETOOTH and HAVE_LIBBLUEZ can be
used interchangeably, which is true for this initial version. When
support for other platforms gets added, the common and the specific
parts need to get sorted. Trying that now would involve guessing. :)
Adding Bluetooth communication is desirable for all sigrok supported
platforms. The BlueZ library is available on Linux which will receive
support first. Check for the BlueZ library's presence, determine a
HAVE_BLUETOOTH summary state, and extend the HAVE_SERIAL_COMM check.
Print version details for the external library.
This commit extends build support and version information, but does not
yet include the implementation of the serial transport primitives.
Register another driver for the UNI-T UT612 LCR meter, which is based on the
ES51919/ES51920 chipset, too. This device had been usable before when the
internal UART connection was made accessible (read: with a hack). It became
officially supported in unmodified form with the addition of transparent
serial over HID support for SiLabs CP2110 chips.
Switch the UT32x driver from running specific USB transfers to generic
serial communication. Preset the bitrate and frame format, but allow for
user specified overrides as well. Default to the WCH CH9325 HID chip,
but allow for overrides or more specific selection so that users can
resolve ambiguities with multiple cables.
The switch from libusb to hidapi removes a limitation that specifically
was reported for the Mac platform. The serial-over-HID variant should
now work as well. See bug #555.
Drop the background transfers. Stick with a local acquisition stop
routine, because a STOP request needs to get sent to the device. Reduce
the receive buffer size such that either blocking or non-blocking calls
will work. The additional flexibility of the buffer handling and packet
processing does not harm.
Do implement the transport methods for serial communication underneath
the common layer, by communicating HID requests and payload data by
means of HIDAPI library calls.
This commit adds the common logic of serial-over-HID communication and
implements the full internal serial transport API, including reception
in the background. But it does not yet support a single HID chip (which
each run their own proprietary protocol).
The implementation works with either hidapi-libusb or hidapi-hidraw
variant of the HIDAPI library, but was only tested on Linux.
Search for the optional HIDAPI library. Call the library's init and exit
routine, and print version information. Extend the common serial layer's
code paths for open, list, and find USB to also support serial over HID.
This commit prepares serial over HID, but the HIDAPI specific transport
for serial communication still is empty in this implementation.
Add a local RX buffer to the common code of libsigrok's serial layer.
Callers of the serial layer's API won't notice, this is an internal
detail of how alternative transports receive their data from the
physical line, and pass it to read() calls emitted by device drivers.
The libserialport specific code still calls into the library, and does
not use the RX buffer. Future HID and BLE support will use the buffer.
Add guards around the implementation of ES51919 chip support for LCR, as
well as modbus and SCPI over serial. To accept when the source files get
compiled in the absence of their dependencies, end up with an empty
implementation in that case.
This approach can simplify build rules when several optional external
dependencies result in differing sets of supported communication means.
Only reference the libserialport header when the library is available.
Allow to always compile the serial.c source file, but optionally end
up with an empty implementation. Make the sr_serial_dev_inst symbol
available outside of HAVE_SERIAL_COMM such that empty stub code can
compile. This prepares the introduction of alternative transports for
serial communication, while all of them remain optional.
The libsigrok serial layer internally uses parity and flow control
symbols which are provided by libserialport. Optionally locally declare
these symbols when libserialport is not available.
A previous commit introduced the more generic "have serial communication"
condition, and adjusted the list of available libsigrok dependencies.
This commit adjusts device driver dependency declarations. This allows
to build e.g. DMM drivers in the presence of RFCOMM support but in the
absence of libserialport, because any of several optional external libs
can make serial communication available.
Introduce the HAVE_SERIAL_COMM identifier, which gets derived from, but
need not be identical to the HAVE_LIBSERIALPORT condition.
Derive the NEED_SERIAL automake condition from the general availability
of serial communication not the specific libserialport library.
Adjust source code references. Stick with HAVE_LIBSERIALPORT where the
specific library is meant, but switch to HAVE_SERIAL_COMM where the
availability of serial communication in general is meant.
Add an indirection between the common serial communication code and the
libserialport specific support code. Prepare the use of alternative
transports like USB HID in the future. Decide in the open() routine
which transport to use for subsequent operations (based on port names).
In theory only the transport specific layer depends on the libserialport
library's availability. In this implementation all support for serial
communication still depends on the HAVE_LIBSERIALPORT preprocessor
symbol. This needs to get addressed in later commits.
Eliminate a direct libserialport dependency in the OLS device driver.
Use libsigrok's internal serial layer's API instead to check for the
availability of receive data.
Add a serial_has_receive_data() routine to the serial layer's API which
returns the number of (known to be) available RX data bytes. Implement
support in the libserialport specific code.
Introduce a new serial_libsp.c source file, and move code from serial.c
there which is specific to libserialport. Keep the existing serial.c API
in place, this is a pure internal refactoring.
Adjust a little whitespace while we are here. Rearrange long lines to
keep related parameter groups adjacent (like pointer and size, or UART
frame length and flow control). Consistently reduce indentation of
continuation lines.
Store the most recent successfully applied set of parameters for serial
communication. Re-use these values as a fallback to calculate timeouts,
when the underlying transport fails to provide the current settings.
The rohde-schwarz-sme-0x device driver used to unconditionally reference
a libserialport header file. Remove that reference, it's not needed in
this specific driver.
Build support has changed to use linker sections for driver registration.
Update the subsection in the HACKING document which discusses the manual
addition of device drivers, to match what the new-driver script does for
driver authors.
Don't exit with an error if the FPGA is detected as unsupported.
Just issue a warning with the detected version and continue. I have such
a clone and it works with the original Saleae software and with sigrok
despite the fact that its FPGA version is 0xff.
Explicitly use SRCDIR and BUILDDIR in Doxyfile files to reference input
files. This seems to be a sufficient fix for an issue where the build
would fail when libsigrok/ was located in a directory that was a symlink.
This fixes bug #547.
Their commands are very similar to the U123x series, they just
add some more modes and the second channel. So use the re-functions
and just extend them where necessary.
Log reading not supported yet.
Basic testing done with a U1272A.
- fix the resolution of the CONF?-response:
the resolution is given with 6 decimal places
(instead of 8) like this:
VOLT +5.000000E+00,+1.000000E-04
- add more measurement modes that are possible with the meter:
CONT,COND,TEMP,PULS
It's important to remain aware that the serial layer's flush and drain
semantics differs from e.g. filesystem calls. The libserialport API is
said to follow the termios example.
Extend comments in the libsigrok API, to not depend on the libserialport
layer and the availability of its documentation. This raises awareness
during maintenance of sigrok device drivers, as well as the pending
addition of alternative transports for serial communication.
Adjust the doxygen comment for the read line routine while we are here.
Add "in" and "out" attributes for routine parameters.
The src/hardware/ subdirectory exclusively contains device drivers these
days, while common support code has moved to the src/dmm/, src/lcr/,
src/scale/, etc directories or src/ itself. Adjust comments in the
libsigrok-internal.h declaration blocks which reference source files.
Just allocate the memory needed to hold the very variable's size. No
need to duplicate the variable's type. Reduces redundancy and increases
robustness during maintenance.
Use g_malloc0() in sr_serial_new() to make sure all of the structure is
initialized.
src/hardware/sysclk-sla5032/protocol.c: In function ‘la_start_acquisition’:
src/hardware/sysclk-sla5032/protocol.c:244:8: warning: implicit declaration of function ‘max’ [-Wimplicit-function-declaration]
pre = max(pre, 2);
^~~
Without a measured quantity in packet.meaning->mq the C++ binding function
sigrok::Analog::mq() throws an exception and there is no way to check if
there is any measured quantity set in the analog package.
Add support for the Pepino-style of accessing >256K of memory. Because
this the only known extension of accessing >256K currently, we apply it
as soon as the sample size is bigger than 256K. Let's hope other
devices (if any) will follow this style. If not, we need to add support
depending on the device name later.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Magnus (creator of the Pipistrello) confirmed that he mixed up the
register names. The code was doing it correctly nonetheless but was
confusing to read because of this. Fix it to make it easier to
comprehend.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Let max_channels really carry the number of maximum channels the
hardware supports. We will handle the limitation of only half the
channels available in 200MHz mode later. Note that there won't be a
regression because we only set the variable but never check it. The
desired result of this patch is the removal of the NUM_CHANNELS macro.
The number of channels needs to be dealt with at runtime.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
We needs this twice so put it into a seperate function, so updates to it
will automatically handled for both callers.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
commit f51acd69 ("ols: combine demux samples") wrongly replaced the bit
pattern of 0x20 with the number of channels which just happens to be 32
as well. So, the code works but is confusing to read. Reword the
for-loop to make it more comprehensible.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The OLS protocol sends 16bit values to specify the sample count and
delay count. However, this 16bit value is the number of 32bit words to
be sampled, so the actual sample count is 4 times larger and does not
fit into a uint16_t. Extend it to support the full range of 256K
(LogicShrimp will need this) and to prepare support for devices with
even more memory (Pepino).
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The previous implementation assumed that a receive data chunk ends
exactly with a sensor packet's end. Yet the buffer had 32 bytes while
the packets have 19 bytes.
Separate the data reception from the packet processing. Collect whatever
chunks the USB connection provides, and scan the resulting buffer for
packets. Cope with either incomplete or corrupt or misaligned packets as
well as with multiple packets in receive chunks. The latter might happen
upon initial synchronization, when a device already sends data or the
serial port buffered previously communicated data.
In the regular case, the computer will process so fast that each single
character will be handled individually. We don't mind. The frequency is
some 60 times per second, and the data volume is 19 bytes. The software
works for the regular case, and synchronizes fast at startup or after
comm errors.
Always print the data bytes of received buffers in the packet parser,
then check some more fixed fields to not process invalid packets, then
process the packet content as the previous implementation did.
Call the packet parser for incomplete packets and discarded input
buffers as well (initial synchronization, re-sync after comm errors).
This results in the availability of more diagnostics during development.
Pass the packet's location and size from outside. This prepares the
logic to cope with situations where the receive buffer contains multiple
(potentially incomplete) packets.
Slightly unobfuscate the UT32x packet parser. The protocol is mostly
ASCII based, checks for hex numbers may be unexpected. Use symbolic
identifiers for the packet length and some special characters.
The previous implementation of the UT32x driver expected to see a conn=
spec, without it no device is found. Default to the USB identification
of the CH9325 chip, to make the driver work out of the box. Users still
can provide conn= specs and override the default for other cables.
Slightly rephrase README.devices since there is no strict distinction
into "fully automatic" and "always manual". Some drivers _accept_ conn=
specs when provided, _and_ support automatic detection of enumerable
devices, _and_ might implement defaults but also support overrides.
Nit, numerically sort the list of Uni-T cables (which is about to grow
in the future) for improved readability.
Add two more devices which require users to manually enable the serial
communication (Brymen BM257s, EEVBlog 121GW).
Fill in the scan, open/close, get/set/list, acquisition start/stop logic
such that data acquisition with a PICkit2 works.
Trigger support needs more attention. User specified triggers either
seem to not take effect, or the trigger position is not in the expected
location. It's yet to get determined what's the issue.
This implementation is based on protocol information gathered from the
pk2-la project.
Remove a free() call in an error path for a list which immediately
before the call was determined to be NULL. Use index 0 and 1 for
channels P1 and P2 respectively (the previous implementation used 0
for both channels).
The current implementation of the SCPI DMM driver is conservative about
checking the device's being operational, but the *OPC? queries are found
in unfortunate locations. Run the OPC query right before running the
next "actual" command, not afterwards. And certainly not between sending
requests and potentially gathering responses in subsequent calls.
This commit does not change current behaviour, but improves maintenance
before pending commits.
The "get MQ" helper routine communicates SCPI responses and translates
them to internal "MQ and flag" values. Optionally return the MQ table
entry reference to callers, so they don't have to repeat the table
lookup when the function's default precision is required, or should
future "start acquisition" requests need to refer to the meter's current
function.
Supported SCPI DMM devices will differ in the set of options and whether
parameters can get queried or configured. Use a "generic" set of devopts
during scan and for simpler models, prepare support for other sets of
devopts for more complex models.
Implement the scpi-dmm driver in such a generic way that it could work
with several protocol variants and with differing models which happen to
use any of these protocol variants. Prepare a list of supported models
with their respective SCPI command set, set of DMM functions and their
precision.
Add support for Agilent 34405A. The ten functions of this device got
tested and are operational, in continuous mode as well as with sample
count or capture time limits. The driver can query the current meter's
function, can change the function, and can run acquisitions in either
the current mode or with a user specified function selection. There is
some potential for improvement: AUTO/MIN/MAX/HOLD indicators are not
supported by this implementation.
The SCPI protocol may communicate strings in quoted form, enclosed by a
matching pair of single or double quote characters, and occurances of
this very quote character within the string get doubled (escaped). Add a
common routine to undo the quotes.
Free the SCPI hardware info after successful model detection, too. Only
allocate the device instance when a supported model was found. Link the
device context earlier right after allocation, for easier verification.
The Fluke 45 probe routine tries to detect whether the serial port is
"in echo mode" (which already is questionable before the IDN query).
In the absence of a response, the library segfaults. Fix it.
==214948== 16 bytes in 1 blocks are definitely lost in loss record 161 of 6,440
==214948== at 0x4C2EE0B: malloc (vg_replace_malloc.c:299)
==214948== by 0x650F435: g_malloc (in /usr/lib64/libglib-2.0.so.0.5600.3)
==214948== by 0x6527056: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.5600.3)
==214948== by 0x65284B0: g_slist_copy_deep (in /usr/lib64/libglib-2.0.so.0.5600.3)
==214948== by 0x592BBA6: sr_session_dev_list (session.c:402)
==214948== by 0x56EF7B5: sigrok::Session::Session(std::shared_ptr<sigrok::Context>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) (classes.cpp:932)
==214948== 16 bytes in 1 blocks are definitely lost in loss record 162 of 6,440
==214948== at 0x4C2EE0B: malloc (vg_replace_malloc.c:299)
==214948== by 0x650F435: g_malloc (in /usr/lib64/libglib-2.0.so.0.5600.3)
==214948== by 0x6527056: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.5600.3)
==214948== by 0x65284B0: g_slist_copy_deep (in /usr/lib64/libglib-2.0.so.0.5600.3)
==214948== by 0x592BBA6: sr_session_dev_list (session.c:402)
==214948== by 0x56F1EB1: sigrok::Session::devices() (classes.cpp:967)
Align the scaling items such that all numbers are aligned. Drop unneeded
"prefixes" for the 2nd display's tables, the main and sub displays already
have their individual tables which reside in their respective groups.
Add an "eevblog-121gw" subdriver entry for the EEVblog 121GW multimeter.
Use device dependent channel names instead of the default "P1" etc names.
It's assumed that the device's binary packet data is available at a COM
port. This means that an external BT to UART gateway is required until
BLE communication will be one of libsigrok's native connection types.
Introduce the dmm/eev121gw.c source file with parse routines for the
EEVblog 121GW meter's 19-bytes binary packets. Get the values and MQ
properties of the device's several displays (main, sub, bar) in several
individual parse calls.
This commit introduces initial support for the device. Some of the modes
and features are untested, as are some of the device's ranges.
Due to some SCPI command changes that Siglent made, the connection
failed due to the wrong commands being send to the device.
This might fix parts of bug #1242, though initial tests show that
further changes might be needed.
[Note: This commit consists of multiple squashed commits from
marchelh <marchelh@gmail.com> and various fixups and rebasing
operations by Uwe Hermann <uwe@hermann-uwe.de>]
Regular operation of serial DMM drivers optionally can dump packet bytes
after the intialization phase has synchronized to the stream. Failure to
synchronize to the stream left developers without a dump, which complicates
research what went wrong.
Do dump packet content while the serial_stream_detect() routine tries to
synchronize to the stream. Use the spew level since the dump occurs upon
every attempt, which translates to: every received byte until a valid
packet was seen (or the synchronization phase expired).
The previous implementation always dumped 23 data bytes for received
packets. This could result in truncated diagnostics information, and/or
access to invalid buffer content.
Rephrase the packet dump routine such that the specific meter's exact
packet length gets dumped, and use the common hex dump support code.
Introduce common support for hex dumps in the string util collection.
There are explicit allocation and release routines for the textual
representation of the data bytes, so that callers are free to chose
whether and how to decorate the dump and where to send the message.
Keep (part of) previous results around when the VCD input module gets
reset, and check the header of the next import against previous runs to
avoid issues in applications. This addresses the VCD specific part of
bug #1241, and resolves the remaining part of bug #1306.
Applications are not prepared to handle changes in the channel list
between multiple acquisitions from the same source (device drivers
or input modules). Introduce common helpers to compare channels and
channel lists.
There was the sr_channel_new() allocation routine, but releasing that
allocation was open-coded in call sites. Add the sr_channel_free()
routine for code re-use and consistency.
This addresses part of bug #1306. The reset() method of the VCD input
module was incomplete, and did not process new data upon second read.
Improve robustness and add missing reset instructions. Void invalid
pointers and avoid NULL dereferences in cleanup paths.
Example:
In file included from src/hardware/kecheng-kc-330b/protocol.h:26,
from src/hardware/kecheng-kc-330b/api.c:22:
src/hardware/kecheng-kc-330b/api.c: In function ‘config_list’:
src/libsigrok-internal.h:51:34: warning: division ‘sizeof (void *) / sizeof (void)’ does not compute the number of array elements [-Wsizeof-pointer-div]
#define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
^
src/libsigrok-internal.h:55:32: note: in expansion of macro ‘ARRAY_SIZE’
#define ARRAY_AND_SIZE(a) (a), ARRAY_SIZE(a)
^~~~~~~~~~
src/libsigrok-internal.h:964:43: note: in expansion of macro ‘ARRAY_AND_SIZE’
std_opts_config_list(key, data, sdi, cg, ARRAY_AND_SIZE(scanopts), \
^~~~~~~~~~~~~~
src/hardware/kecheng-kc-330b/api.c:296:10: note: in expansion of macro ‘STD_CONFIG_LIST’
return STD_CONFIG_LIST(key, data, sdi, cg, NULL, drvopts, devopts);
^~~~~~~~~~~~~~~
Default to the existing "P1" etc naming scheme for analog channels of
serial-dmm subdrivers. Add support for subdriver specific channel names
(which can reference the channel number if they desire). This is useful
for devices with multiple displays, or special purpose devices where
other names than P1 can better reflect the channel's nature.
Commit 556a926d43 introduced support for multiple displays in
subdrivers of serial-dmm, but also changed user visible channel numbers
to start from 0. Restore the previous behaviour, start counting from 1
which users may perceive as more natural (serial-dmm used to start at P1
in the past, scopes start with CH1 as well).
There are code paths where dev_close() tries to access a USB handle
which does not exist. This was observed with this command:
$ sigrok-cli -d brymen-bm86x --scan
On Windows, this device can either enumerate as 04b4:602a or 04b5:602a,
depending on which vendor driver is currently being used, so we have to
support both in the hantek-6xxx driver as well.
This fixes bug #1295.
In the case where the input unit was not in the array, the for loop would
complete, but the following test would then read past the end of the array
since 'i' would already have been incremented to the array size.
Spotted because unitless data was getting SI prefixes with no unit, though
this would not have been deterministically reproducible.
This fixes parts of bug #950.
The comment says "A requested value is certainly on the way", but the code no
longer works this way. The receive handler requests a value and blocks until
it is received. There is no value pending between receive handler calls, so
this code now only leads to a timeout.
Applications might pass NULL for the buffer, and input modules might
accept it (or just cope). Eliminate a potential NULL dereference in
the emission of diagnostics messages.
On Windows, this device can either enumerate as 04b4:6022 or 04b5:6022,
depending on which vendor driver is currently being used, so we have to
support both in the hantek-6xxx driver as well.
This fixes bug #918.
This is happening because the send() and recv() functions
have different prototypes on POSIX and Windows. Using the casts
is required on Windows and doesn't hurt on POSIX systems.
[...]/protocol.c: In function 'tcp_send':
[...]/protocol.c:161:26: warning: pointer targets in passing argument 2 of 'send' differ in signedness [-Wpointer-sign]
out = send(tcp->socket, buf, len, 0);
^
In file included from [...]/protocol.c:24:0:
[...]/include/winsock2.h:997:34: note: expected 'const char *' but argument is of type 'const uint8_t * {aka const unsigned char *}'
WINSOCK_API_LINKAGE int WSAAPI send(SOCKET s,const char *buf,int len,int flags);
^
[...]/protocol.c: In function 'ipdbg_la_tcp_receive':
[...]/protocol.c:201:32: warning: pointer targets in passing argument 2 of 'recv' differ in signedness [-Wpointer-sign]
int len = recv(tcp->socket, buf, 1, 0);
^
In file included from [...]/protocol.c:24:0:
[...]/include/winsock2.h:992:34: note: expected 'char *' but argument is of type 'uint8_t * {aka unsigned char *}'
WINSOCK_API_LINKAGE int WSAAPI recv(SOCKET s,char *buf,int len,int flags);
^
[...]/protocol.c: In function 'data_available':
[...]/protocol.c:73:38: error: 'bytes_available' undeclared (first use in this function)
ioctlsocket(tcp->socket, FIONREAD, &bytes_available);
^
[...]/protocol.c:73:38: note: each undeclared identifier is reported only once for each function it appears in
[...]/protocol.c:84:1: warning: no return statement in function returning non-void [-Wreturn-type]
}
^
The fx2lafw(4) driver supports mere logic analyzers as well as mixed
signal devices, but does not support channel group specific device
options. Avoid an error message when channel group device options get
queried, the condition is perfectly legal and non-fatal.
How to reproduce:
$ pulseview -d fx2lafw
$ sigrok-cli -d fx2lafw -g Logic --show
This fixes bug #1267.
The "firmware load failed" message would be even more helpful if users
could learn which firmware file failed to load. Add those filenames to
various FX2-based drivers.
This addresses bug #1262.
As per Daniel Anselmi <danselmi@gmx.ch> in an email conversation, the
code was actually written by Eva Kissling <eva.kissling@bluewin.ch>
(as indicated in the commit logs as well). Fix the headers accordingly.
Use "ipdbg-la" everywhere to refer to the driver, including
in function name prefixes etc. There's no need to encode
website details (.org) into the driver/function name(s).
bindings/cxx/classes.cpp: In function ‘int sigrok::call_log_callback(void*, int, const char*, __va_list_tag*)’:
bindings/cxx/classes.cpp:242:17: warning: catching polymorphic type ‘class sigrok::Error’ by value [-Wcatch-value=]
} catch (Error e) {
^
In file included from bindings/cxx/classes.cpp:1667:
bindings/cxx/enums.cpp: In static member function ‘static Glib::VariantBase sigrok::ConfigKey::parse_string(std::__cxx11::string, sr_datatype)’:
bindings/cxx/enums.cpp:789:13: warning: catching polymorphic type ‘class std::invalid_argument’ by value [-Wcatch-value=]
} catch (invalid_argument) {
^~~~~~~~~~~~~~~~
bindings/cxx/enums.cpp:804:13: warning: catching polymorphic type ‘class std::invalid_argument’ by value [-Wcatch-value=]
} catch (invalid_argument) {
^~~~~~~~~~~~~~~~
With gcc 8 this yielded:
src/input/wav.c: In function ‘receive’:
src/input/wav.c:345:51: warning: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 6 [-Wformat-truncation=]
snprintf(channelname, sizeof(channelname), "CH%d", i + 1);
^~
src/input/wav.c:345:48: note: directive argument in the range [1, 2147483647]
snprintf(channelname, sizeof(channelname), "CH%d", i + 1);
^~~~~~
src/input/wav.c:345:5: note: ‘snprintf’ output between 4 and 13 bytes into a destination of size 8
snprintf(channelname, sizeof(channelname), "CH%d", i + 1);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Test the ".1" and "1." cases which are assumed to be problematic on
MacOS (or may not have been supported before a recent update). Add more
tests with leading signs as well as whitespace instead of a sign.
The previous implementation accepted either empty integer or empty
fractional parts of a floating point number, but also when both parts
were missing ("." input). Insist in at least one of the parts to be
present.
Programmatic output of floating point numbers might choose to print
spaces instead of an explicit '+' sign, to align the output with the
result of formatting negative numbers yet achieve a screen appearance
similar to what humans would have written. Skip leading whitespace
before insisting in seeing either signs or digits or decimals.
Accept numbers like "123." where the period (dot) is present yet the
fractional part is empty. Adding a period but no additional digits is a
popular method of turning an otherwise integer literal into a float.
Compilers and strtod() routines accept this notation, too, so we have to
expect seeing such input.
The previous implementation only echoed the p/q conversion results _if_
the return code signalled success but the result was unexpected. Although
the errno value for failed conversion attempts (non-zero return codes)
is not too helpful, seeing which text input failed the test is desirable.
The VCD specification requests that timestamps will strictly increase as
one advances through the file. Add another check where the previous
implementation resulted in a tight loop and made the application stall.
Do print an error message and abort file processing in that case.
This fixes bug #1250.
Adjust the calculation of the '^' marker's position in T: lines of the
-O ascii/bits/hex output modules such that it matches the sample data
lines' layout. Add comments which discuss the motivation of the marker
position's calculation, which differs among each of those modules.
Strictly speaking -O bits was already correct. But I chose to adjust and
comment the logic such that multiple output modules follow a common
pattern. If performance is an issue, the bits.c change might be worth
reverting.
This commit fixes bug #1238.
- add support for multiple transfers.
- set nummber of samples to 1 for FPGA FW version 0
- increase size of data transfer buffer to 2kB.
Signed-off-by: Andrej Valek <andy@skyrain.eu>
Callback for data transfer is separated from status. This change will be
used for better data transfer sending/receiving. Cast signal, that trigger
has been captured was moved into state: H4032L_STATUS_FIRST_TRANSFER.
Signed-off-by: Andrej Valek <andy@skyrain.eu>
- get FPGA version in dev_open
- enable some features only for newer FPGA
- decrease printing number of message of FPGA version
Signed-off-by: Andrej Valek <andy@skyrain.eu>
Split the creation of channels and groups as well as the creation of the
session feed buffer into separate routines. Re-allocate the buffer after
reset but do not re-create the channels and groups.
This implementation assumes that after reset() of the input module, the
very same set of channels (including their order, names and enabled
state, as well as group membership) results from processing the
subsequently fed file content. Reading rather different configurations
from the same input file by means of repeated reset and re-read may not
work as expected.
Explicitly check GString pointers for validity before calling glib
routines that would access string content. This silences an assertion
error for a non-fatal runtime condition:
(process:17044): GLib-CRITICAL **: g_string_free: assertion 'string != NULL' failed
Rephrase common input reset logic such that additional common code can
execute after the individual module's reset callback. No behaviour has
changed, the module's reset callback still is optional, and identical
log output gets emitted.
Do clear the sdi_ready flag in the common sr_input_reset() routine, so
that all input modules will parse header information again before
processing sample data when subsequent calls receive new file content.
Void the input module's receive() buffer from common reset code. This
unbreaks the feature of re-reading previously consumed input files.
Extend comments in the common reset and free code paths, which involve
the modules' reset and cleanup routines, which interact in non-trivial
ways. Discuss the responsibilities of common and individual routines, to
remain aware during maintenance.
Acquisition won't work correctly in a multi-threaded environment, when
config_set() and config_get() are called with a channel group.
The channel switching itself has moved to scpi/scpi.c, to be able to
handle switching in a thread safe way.
Use of the thread safe SCPI functions, so no write+read operation is
interruped.
Also return float values instead of double value in acquisition mode.
This is related to bug #779.
This ensures that SCPI read/write/write+read operations are thread safe.
F.e.: If a write operation expects a return value (in other words: a
read operation), it is not allowed to be interrupted by another write
operation.
To simplify things, the SCPI helper functions are moved from
scpi/helpers.c to scpi/scpi.c and also are renamed to fit the naming
scheme.
libgpib in particular will abort the program execution in case of
concurrent operations.
The chronovu_la8 input module is capable of handling either file type,
generated by LA8 or LA16 vendor software. Automatic detection is not
available, but user provided channel counts work fine.
Adjust the input module's name and description, and claim support for
.kdt as well as .kd1 files.
Add developer notes on implementation details, the file content's
constraints, and potential future adjustment.
The file format is funny, a data part is leading (fixed size) and a
"header" part follows. The previous implementation sent the header part
to the session, too, pretending it was part of the data. This change
limits the number of samples that get sent to the session.
Comment on the file layout and header fields while we are here. This
information got lost in commit 02e24c0ce0 when the input module got
converted from do-it-yourself file operations to having intrinsic
handler routines invoked from common logic which handles the file.
Prefer the more portable UINT64_C() macro over the UL suffix when a
literal needs to span "more than 31 bit positions". Adjust other
locations for consistency across the source file.
Commit 8c4bff1d25 introduced a routine which prints what mostly should
be text, and avoids non-printable characters. This implementation used an
incorrect format string, which could result in data getting written past
the end of a buffer. Fix the format string.
src/hwdriver.c: In function ‘log_key’:
src/hwdriver.c:648:13: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
opstr = op == SR_CONF_GET ? "get" : op == SR_CONF_SET ? "set" : "list";
^~
src/hwdriver.c: In function ‘check_key’:
src/hwdriver.c:681:13: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
opstr = op == SR_CONF_GET ? "get" : op == SR_CONF_SET ? "set" : "list";
^~
src/hardware/siglent-sds/api.c:596:3: warning: Argument to g_free() is the address of a global variable, which is not memory allocated by malloc()
g_free(cmd);
^~~~~~~~~~~
src/hardware/siglent-sds/api.c:641:3: warning: Argument to g_free() is the address of a global variable, which is not memory allocated by malloc()
g_free(cmd);
^~~~~~~~~~~
Reported by scan-build:
src/hardware/lecroy-xstream/protocol.c:680:12: warning: Potential leak of memory pointed to by 'analog.data'
return SR_ERR;
^~~~~~
Reported by scan-build:
src/input/logicport.c:1186:18: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
.format_match = format_match,
^~~~~~~~~~~~
Allow C++ applications to have the input format automatically detected,
and get a corresponding InputFormat instance. This makes the format match
logic available to PulseView.
Log determined header format when parsing trace32 file headers. Keep
another log message during regular processing, but silence it during
format match.
Use more appropriate data types for local and instance variables. Adjust
format strings accordingly.
There were several issues with the previous implementation of the logic
which parses trace32 input files: A string comparison was inverted, and
compared a seven character literal to a five character copy of the input.
One more character was trimmed before CTRL-Z (the CP/M EOF), which often
is SPACE in input files, but might be excessive on other input files.
Replace a DIY character search while we are here. Use symbolic names for
special characters. Factor out a test and memory release, to simplify
error code paths in the remaining logic. Extend comments.
There is not much point in log messages about format mismatch in the
auto detect phase, where each module gets queried in turn and most are
supposed to not match.
Do not print non-printable characters in log messages. Those could occur
in the format detection phase, or in the regular processing of input
files that either are unexpected or invalid (or is there a binary header
format variant even?).
Although the file format handled by this input module appears to be of
fixed size (8MiB plus 5 more bytes), it's more reliable to use a data
type for the file size that is larger than "an int". Although off_t
would be most portable, use uint64_t to match the code which passes the
parameter to the input module.
The previous implementation already was inconsistent (used to allocate
255 bytes and claimed that 128 bytes were sufficient). While existing
formats already required more than a few bytes of input (regular VCD
files' header sections exceed 255 bytes length).
Increase the buffer size that gets passed to input modules' match
method. Use 4MiB for consistency with other locations. Do not enforce a
minimum size, as there are valid input files which are shorter than 128
bytes. Auto-detection failed on those.
This addresses part of bug #1200.
When users don't specify the input format, applications can try to have
the format auto-detected. Some of the tests were weak and could result
in false positives.
Add a 'confidence' parameter to the input modules' format_match()
method. Claim high confidence (1) for those formats which can check
magic strings or the presence of essential keywords (vcd, wav). Claim
medium confidence (10) for those formats which happened to mis-detect
inputs in the past (trace32_ad). Claim weak confidence (100) for those
formats which totally lack reliable conditions and rather guess than
detect (chronovu_la8).
Prefer the best match in public scan routines. Return at most one module
to callers even if multiple modules matched, to keep the current API.
This addresses part of bug #1200.
Implement an input module for .lpf files, the "LogicPort File" format of
the Intronix LA1034 vendor software. This version supports wires with
enabled and inverted state, compressed samples, signal names, signal
groups (but not multiple assignment), and automatic format detection.
The logic which determines whether "the file header" was completely
received, and sample data can get sent to the session, implements an
assumption in the absence of a better and more reliable condition.
Invalid input gets rejected, but diagnostics is rather limited. Since
all channels get to be the member of a channel group, either specified
by the user in the input file, or arranged for in the input module, the
"missing separator" part of bug 1186 has become obsolete.
../include/libsigrok/libsigrok.h:653:19: warning: result of ‘1 << 31’ requires 33 bits to represent, but ‘int’ only has 32 bits [-Wshift-overflow=]
SR_CONF_GET = (1 << 31),
^~
[...]
src/analog.c:205:23: warning: declaration of ‘i’ shadows a previous local [-Wshadow]
for (unsigned int i = 0; i < count; i++) {
^
src/analog.c:178:18: note: shadowed declaration is here
unsigned int b, i, count;
^
[...]
src/analog.c: In function ‘sr_analog_to_float’:
src/analog.c:194:9: warning: declaration of ‘offset’ shadows a previous local [-Wshadow]
float offset = analog->encoding->offset.p / (float)analog->encoding->offset.q;
^~~~~~
src/analog.c:177:8: note: shadowed declaration is here
float offset;
^~~~~~
Allow developers to specify the (default) number of frames at compile
time (default to "off" as before). Accept the frame limit spec at scan()
time as well. This is useful when applications don't run config_set() at
runtime.
Tested with:
$ pulseview -d demo:logic_channels=0:analog_channels=1:limit_frames=4
The previous implementation supported the generation of frames as a
compile time option. This change lets users adjust the feature at
runtime.
In the absence of a frame count limit no frame begin/end markers get
sent (the default behaviour of the previous implementation). When a
frame count limit is specified, the respective number of frames gets
sent and acquisition stops.
The fixed amount of 1000 samples per frame is an arbitrary choice. This
compile time option is easily adjusted in the source code.
Introduce support for the "graycode" logic pattern. Generate up to
64 bits of graycode output (all logic lines, no repetition, not limited
by the generator's internal pattern buffer). The implementation was
tested with 16 channels.
Keep a context variable around with a bit mask for all logic channels.
This is convenient in setup and generation routines, to avoid garbage
in unassigned bit positions of session feed packets.
Move the declaration of codes for pattern types before the declaration
of the context container such that the latter can reference the former.
Add 'int' to an unsigned variable that omitted the base type.
When auto-detection tries to find the input module that can handle a
file, unexpected input format should be considered non-fatal. Only emit
error messages when process_header() got invoked from process_buffer()
after initialization. Emit debug messages in early stages where no input
module context exists yet.
The initial voltage threshold in dev_open() was being set to a
default value in the devc->cur_threshold variable but not actually set
in the device itself.
Patch by Jörg Alpers <jalpers@gmx.net>, thanks a lot!
- fix LIBUSB_TIMEOUT errors
- fix same data receiving
- send reset vendor request before new data getting
- decrease USB polling timeout
This fixes bug #1190.
Signed-off-by: Andrej Valek <andy@skyrain.eu>
- use pragma to handle different behavior between gcc and minGW bit-field packing
- bit-field integer variables needs to be align to 2-byte boundary
Compiler does not produce an error when accessing into non-__packed pointer.
However, the field might not be properly aligned for this type.
More information could be found on:
- https://sourceforge.net/p/mingw-w64/bugs/275/
- http://www.keil.com/support/man/docs/ARMCC/armcc_chr1359124990875.htm
Signed-off-by: Andrej Valek <andy@skyrain.eu>
Before this change, the loglevel check would only be performed for the
default log handler in libsigrok, but not for other handlers set
via sr_log_callback_set().
This fixes bug #698.
A local buffer was too small, snprintf() was used to write the
name of the analog-1-1-xxx ZIP archive names in that buffer.
Due to the limited size, only 3 characters were usable for the last
number component, i.e. the code would loop around from analog-1-1-999
to analog-1-1-100 (instead of analog-1-1-1000).
As a quickfix, increase the buffer size by a large margin, a nicer
fix should be used later on.
These trigger quite often with unrelated devices and confuse people.
scpi_usbtmc: Failed to get configuration descriptor: LIBUSB_ERROR_NOT_FOUND, ignoring device.
The Modbus RTU implementation was inappropriately returning lengths
from the serial functions when the calling functions expect only an
sr_error_code value.
Make sure to not exceed the ctx->analog_samples[] array bounds. Don't
use the (huge) channel's index in the device's(!) channel list, instead
use the zero-based and dense index into the array of analog samples in
the accumulation buffer, before writing to the external file.
This fixes the segfault reported in bug #1124.
The process_analog() logic is rather complex, dealing with the total
list of channels in the device (which can be of different types), and a
number of submitted samples for a specified list of channels. Replace
the rather short variable names for i, j, c (and num_channels) with
something longer that hopefully increases readability of the complex
loop bodies.
Note that this change merely renames identifiers, and does not change
behaviour.
Instead of nesting indentation levels upon equality of a value, skip
iterations upon inequality. This reduces indentation, and might improve
readability.
[ Indentation changes, see 'diff -w -b' for the essence. ]
Use serial_readline in acquisition mode, otherwise data from the
Re:load Pro could get lost.
Use reloadpro_receive_data() for all commands when in acquisition
mode. When not using a single point of receiving data, data could get
lost.
Prefer sigrok's endianess conversion helper over the inet htons()
routine which is harder to read (is "network order" little or big?).
Writing the conversion results in units of bytes also avoids misaligned
memory access. The header length is odd, each payload item got written
as an uint16_t item to an odd address.
The config.h file must always be included as first file.
src/output/csv.c: In function 'gen_header':
src/output/csv.c:64:20: warning: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint64_t {aka long long unsigned int}' [-Wformat=]
#define LOG_PREFIX "output/csv"
^
./src/libsigrok-internal.h:753:42: note: in expansion of macro 'LOG_PREFIX'
#define sr_info(...) sr_log(SR_LOG_INFO, LOG_PREFIX ": " __VA_ARGS__)
^
src/output/csv.c:244:3: note: in expansion of macro 'sr_info'
sr_info("Set sample period to %" PRIu64 " %s",
^
src/output/csv.c: In function 'dump_saved_values':
src/output/csv.c:462:34: warning: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint64_t {aka long long unsigned int}' [-Wformat=]
g_string_append_printf(*out, "%" PRIu64 "%s",
^
In file included from src/hardware/ftdi-la/protocol.c:21:0:
src/hardware/ftdi-la/protocol.c: In function 'send_samples':
src/hardware/ftdi-la/protocol.h:28:20: warning: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint64_t {aka long long unsigned int}' [-Wformat=]
#define LOG_PREFIX "ftdi-la"
^
./src/libsigrok-internal.h:751:42: note: in expansion of macro 'LOG_PREFIX'
#define sr_spew(...) sr_log(SR_LOG_SPEW, LOG_PREFIX ": " __VA_ARGS__)
^
src/hardware/ftdi-la/protocol.c:29:2: note: in expansion of macro 'sr_spew'
sr_spew("Sending %" PRIu64 " samples.", samples_to_send);
^
Optionally create multiple analog channels in serial-dmm's scan()
routine. Allow the meters' parse routines to fill in more than one
analog value from the inspection of a single packet.
Use "large" (4 times 14 bytes) packets for the Metex M-3860M and the
PeakTech 4390A meters, and have those large packets parsed by wrapping
the routines for regular 14-byte Metex packets, and sending four values
to the session bus after reception of one large packet.
Thanks to Frank Stettner <frank-stettner@gmx.net> for testing and
fixing the initial implementation of this extension.
Move the initial assignment to the 'offset' variable to the very spot
where it gets evaluated and subsequently manipulated.
Replace a DIY copy loop with the corresponding memmove(3) call.
Also use "r" and "f" as trigger slope values for now, since that's
what most other drivers do currently.
This also fixes two scan-build issues:
api.c:559:3: warning: Value stored to 'tmp_str' is never read
tmp_str = g_variant_get_string(data, NULL);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
api.c:561:9: warning: Use of memory after it is freed
ret = siglent_sds_config_set(sdi, "%s:TRSL %s",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The strcasestr() function is non-portable (e.g. not available on
MinGW, possibly elsewhere). Replace it with g_strstr_len() for the time
being. While the latter is not case-insensitive it appears that
that property doesn't matter here ("." should not be relevant anyway,
and e.g. an SDS1202X-E does indeed report "Mpts" as such).
Should it become necessary to have this code be case-insensitive,
we'll have to find a more portable solution than strcasestr().
This causes some compile errors on platforms where RPC is not available, e.g.
siglent-sds/api.c:25:21: fatal error: rpc/rpc.h: No such file or directory
Surrounding the #include (and later code) with "#if HAVE_RPC" should avoid
these compile errors, but since it's not used at all for now, drop it.
Make the USB reset for USB TMC devices conditional. Check a whitelist,
which in this implementation exclusively contains the Siglent VID.
The whitelist's comment may need adjustment. The VID probably not only
applies to SDS devices, but could be used for SDG and others as well.
And lsusb output suggests the VID is used by Atten, too.
Add the Siglent's VID to a list of blacklisted USB TMC devices.
Unconditionally reset USB devices in the open routine.
This was taken from marchel's development for Siglent SDS. Though the
reset should probably be conditional, and only get applied to devices
which are known to need it.
The comment may need adjustment, maybe individual PID entries are
required. The VID probably not only applies to SDS devices, but could
be used for SDG and other gear as well. And lsusb output suggests the
VID is used by Atten, too.
Implement a first version of the driver for the Siglent SDS1000 and
SDS2000 oscilloscopes.
[ gsi: This commit corresponds to git 0228126017e6 of marchelh's tree,
I adjusted the source to closer match the project's coding style. The
conversion was verified by this command:
$ git diff --word-diff=color -w -b <branch>:<dir> <branch>:<dir>
Changes include: Whitespace adjustment, dead code removal, separation
of variable declaration and assignment, alpha-sorted includes. Line
length was not addressed and not every location got adjusted, to keep
the diff minimal and to reduce effort during review of this version. ]
The conn= specification is not strictly related to RS232 communication.
Provide examples for other USB specs (as they are used for some DMM and
LCR drivers), as well as TCP and VXI (which are often found with MSO
drivers).
Check for successful allocation before accessing struct members. Return
with an error from device initialization when allocation fails.
This was reported by clang's scan-build.
Make sure to release the allocated "pod enabled" memory, too, when SCPI
communication during channel setup fails. Defer the return with an error
(instead of duplicating the free() invocation).
This was reported by clang's scan-build.
The compiler marks a potential use after free, which the current
implementation won't trigger. The error only occurs when a sigrok
channel is neither logic nor analog.
Address the issue nevertheless, to silence the compiler warning, and to
protect against possible programming errors when a future implementation
should support more channel types.
This was reported by clang's scan-build.
Fixup unbalanced braces for more complex if statements, to better
reflect the project's official coding style.
Adjust data types in the float_to_le() routine. A float value gets
copied to a buffer of bytes (uint8_t). Don't use 'char' on the other
side of assignments, to not assume a specific width for char, and to
avoid potential signedness issues. Copy from bytes to bytes instead.
The WAV output module supports an optional 'scale' factor, in its
absence the samples will pass unmodified. The builtin help text is
unexpected, and reads:
$ sigrok-cli -O wav --show
...
Options:
scale: Scale values by factor (default 0.0)
Setup a default scale factor of 1.0, which results in identical
behaviour and better reflects what is happening.
The previous implementation only emitted data for the first enabled
channels, and "saw no changes" after emission of the initial value for
channels on positions that followed a disabled channel.
Assume that the received data from the session bus communicates the bits
of enabled channels in a packed representation. Skip the mapping of
output bit indices to sigrok channel numbers.
This fixes the remaining part of bug #519.
Tested by inspecting in gtkwave the result of command:
$ sigrok-cli -d demo -C D1,D3,D6 -c samplerate=2M --samples 2500 -O vcd -o trace.vcd
When we find that all input sources (device drivers, and input modules)
provide a dense bit field, all of the mapping logic can get removed
here. This commit just quickly disables the logic.
Identifiers for channels in the VCD header section could be "sparse"
when sigrok channels were disabled. Make sure to not assign names to
disabled channels. This will e.g. assign !, ", and # to channels D1, D3,
and D6, when D0, D2, D4-D5, and D7 are disabled.
This addresses part of bug #519.
Few DMM drivers already did it. This commit adjusts the remaining DMM
drivers, to set the "DC" flag for measurements in diode mode.
This fixes bug #144.
Although I don't have the hardware to test, the nature of the change and
the arrangement of driver code suggests it's good. When a meter already
communicated the "DC" status, the change does nothing and won't harm.
The change ensures "DC" is flagged for those meters which previously
didn't, which is desirable.
Some SCPI based drivers fail to convert response data, because strutil
conversion helpers sr_atol() and sr_atof() don't like trailing spaces
after the number's text that successfully got converted.
It's yet to get determined whether all call sites of the conversion
routines like their eating adjacent whitespace. But given that the
conversion routine explicitly checks for end of the string after the
number, no call site should expect or even depend on trailing text to
keep its whitespace.
See bug #788 for a discussion and example data.
Synchronize sr_parse_sizestring() with sr_si_string_u64() capabilities.
Add support for the T/P/E suffixes. Since this conversion helper deals
with integer values exclusively, there is no issue with case insensitive
matches. The value cannot be pico. Neither is there an ambiguity with
the 10e6 notation.
This addresses bug #763.
Fix a style nit while we are here. Put braces around both arms of a
complex conditional.
Explicitly assign NULL to param to avoid the "may be used uninitialized"
warning reported in bug #1094. Behaviour remains unchanged. All references
to the variable were under "if (!conn)", and the assigning arm of the
branch checked for "if (!param)" after assignment. So the error could
not happen, but compilers may not have noticed depending on the width of
their scope during compilation.
Move the initialization of 'conn' closer to the conditional assignment,
such that all paths are seen in one spot during maintenance.
This fixes bug #1094.
Although log messages are terminated by a line feed, output still might
get buffered when the program does not talk to a terminal (that it is
aware of). Add an fflush(3) call to the printf(3) sequence such that log
output will immediately show up when writing to pipes or sockets, too.
Early sr_init() steps can just 'return' fine. After allocation of the
'context' memory, make all error paths 'goto done' before returning,
to undo the memory allocation.
The srzip output module dropped support for the "filename" option in
commit 37875f7506 on 2015-07-30, but still used to assign to slot
options[0] which clobbers the array's sentinel. Remove those accesses
to the non-existing option.
api.c: In function 'config_set':
api.c:352:5: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'uint64_t' [-Wformat=]
sr_err("invalid sample range 2k...64M: %ld",
^
beaglelogic_tcp.c: In function 'beaglelogic_tcp_send_cmd':
beaglelogic_tcp.c:114:3: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'size_t' [-Wformat=]
sr_dbg("Only sent %d/%lu bytes of command: '%s'.", out,
^
Check pointers' validity before dereferencing them. Release partially
allocated memory in an error path. Remove an assignment which never took
effect.
This was reported by clang's scan-build.
Each code path either assigns to 'flags', or leaves the routine. There
is no potential path that leaves the variable at the initially assigned
value, so the assignment took no effect. Remove it.
Nit: Trim the source code line length while we are here.
This was reported by clang's scan-build.
Check pointers' validity before dereferencing them. Explicitly assign a
default value to variables, before conversion routines conditionally
assign the "real" value (and don't in case of conversion errors). This
avoids processing "garbage" data.
Strictly speaking I cannot see how the conversion routine returns OK and
has _not_ assigned a result. But the explicit assignment won't harm
either, and matches the fallback when the conversion fails (detectibly).
Which means that runtime behaviour won't change.
This was reported by clang's scan-build.
Remove an assignment that won't take effect. Check pointers' validity
before dereferencing. Fix a memory leak.
This was reported by clang's scan-build.
Check for successful allocation of multiple memory ranges, and release
partial allocations in the error path when one of them failed. This
fixes a potential memory leak, as well as avoids NULL dereferences.
This was reported by clang's scan-build.
Silence warnings about assigned values that never get used, potential
NULL deference, and potential memory leaks.
This was reported by clang's scan-build.
The scan_2x_bd232() routine used to always prepare one spare context,
and filled it in when a device was found, just to allocate another one
and continue scanning.
Free the last allocated context unconditionally, as it was allocated
unconditionally, and never used.
This was reported by clang's scan-build.
Stick with the prepared but unfinished "limit msec" code path, but
silence the warning about an unused variable value.
This was reported by clang's scan-build.
Avoid a division by zero, by not using a zero unitsize in a modulo
operation. As a byproduct, avoid processing and counting input that
neither has analog nor logic data. This should never have happened,
but the change now catches the error if invalid input is seen.
This was reported by clang's scan-build.
The sr_packet_copy() routine could have written to an arbitrary memory
location. Make sure to allocate the space before writing to it, and
check for successful allocation before accessing the memory.
It's assumed that this error never took effect, as the routine appears
to be unused.
This was reported by clang's scan-build.
The 'opc' variable was only conditionally assigned to (depends on
successful SCPI communication). Ensure there always is a known value.
This was reported by clang's scan-build.
After the first capture ->num_frames never got to be _equal_
to ->limit_frames; fixed by resetting to zero in dev_acquisition_stop(),
and protected against similar problems in the future by switching to
greater-or-equal instead.
[Note: This patch is basically a squashed version of the initial driver
commits by Andreas Zschunke <andreas.zschunke@gmx.net>, two fixes by
Andrej Valek <andy@skyrain.eu>, and various coding style / cosmetic
fixes by Uwe Hermann <uwe@hermann-uwe.de> to make the driver a lot more
consistent with the rest of the libsigrok code-base.]
When refactoring the code, some places where sr_scpi_send was replaced
by rigol_ds_config_set the first argument was not changed from sdi->conn
to sdi. Fix the remaining ones.
Fix: https://sigrok.org/bug/1073
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
This regression was introduced in f1ba6b4b2c.
Due to how the sysclk-lwla driver does up to 3 open/close operations in
one dev_open() API callback we cannot rely on the sr_dev_open() and
sr_dev_close() wrappers setting the sdi->status variable in this case.
Tested on LWLA1034.
When processing of large VCD input files was spread across multiple
parse_contents() invocations, the resulting sigrok stream of sample data
had gaps in them and total timing was off. For instance 74ms of input
data were interpreted as spanning some 600ms or 300ms, depending on the
number of channels in the input stream.
Move the "previous timestamp" variable to the input module context. This
eliminates the inappropriate gaps and fixes the translation of VCD file
timestamps to sigrok sample numbers.
This fixes bug #1075.
Remove vague statements from the README. On all current distributions,
the udev paths are identical, anyone deliberately deviating from the
defaults should be able to handle it by themselves.
Rules in /etc/udev/rules.d/ should only be used for customization, or
for locally built packages.
Split the distribution independent database from the access policy rules.
This avoids warnings due to granting permissions to the commonly unknown
plugdev group, and allows simple overrides of the used access policy.
The "uaccess" tag has to be added before the "seat" rule is evaluated.
The upstream default for the seat rule is "71-seat.rules", so use
60-libsigrok.rules for appropriate lexicographical sorting.
Also use a dash instead of underscore, the latter is commonly used as a
replacement character of unsafe characters in autogenerated identifiers.
This fixes bug #1059.
Some drivers used locale dependent functions for converting strings
to float/double values. These functions fail when the decimal mark
is a "," in the locale settings but the string contains a ".".
This fixes bug #1064.
A "low samplerate" in this case means anything where
samples_todo is less than SAMPLES_PER_FRAME. This case
wasn't handled properly before, resulting in wrong
amounts of data being sent out.
We can't use the memory size command because it returns
the *maximum* memory used, not the *actual* memory used.
Hence, we only know the number of samples per div once
sample data actually comes in.
As there is a huge range of supported LeCroy scopes, naming
the IDN response for every single one of them is going to be
impossible. Hence, it makes more sense to treat all LeCroy
devices as if they were scopes and supported. This approach
lets users try to see how far they get and if they run into
issues, they can then be treated separately - e.g. by creating
a custom device profile.
Unless we do this, the vast majority of LeCroy scopes will
not be recognized by the driver.
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>
The code earlier was in a single .h file, so it's now separated into a C file
and H file
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>
Values like '-0.1' would be parsed as being positive, as the integral
type does not discern +0 and -0. Also allow values without leading
integral value, to match behaviour of strtod/sr_atof.
There were some issues when using libftdi 0.x recently that are fixed
when switching to libftdi 1.x (not really worth the effort to investigate).
libftdi 1.x has been around several years now and should be available
in most recent distros and OSes. For the rare cases where it is not,
it's easy enough to get it via backport packages, or build from source,
or sigrok users can just use our binary installers for most OSes.
This also "fixes"/obsoletes bug #959.
This was leading to an invalid threshold config value and indirectly
to frontend issues.
Slightly modified patch from James Churchill <pelrun@gmail.com>, thanks!
The previous implementation unconditionally submitted analog data
whenever values could get extracted out of received serial packets.
This commit checks the channels' enabled state before submission. Care
is taken to obey the user's acquisition limits, exclusively counting
submitted not received values.
Upon reception of serial data from the ES51919 LCR chipset, the data for
channels P1 and P2 was extracted from the packet, and unconditionally got
sent to the sigrok session.
Do check the channels' enabled state before submission. This fixes for
serial-lcr what recently got reported for a Brymen DMM. Tested with
$ sigrok-cli -d peaktech-2170:conn=/dev/ttyUSB0 --channels P2
and other --channels specifications.
The es51919_serial_clean() routine is called by std_dev_clear_with_callback().
Common code unconditionally frees the 'priv' part. The cleanup callback only
shall release descending resources which are local to the callee and opaque
to the caller.
This fixes a double free error. Tested with PeakTech 2170.
$ sigrok-cli -d peaktech-2170:conn=/dev/ttyUSB0 --show
When the acquisition was stopped before a configured limit was reached,
no sample data was retrieved. This is because the api.c stop routine did
unregister the receive callback.
Pass the stop request to the receive routine instead when stop is called
while the acquisition is still running. Have sample data downloaded very
much like it's done for reached limits, and existing logic will run the
stop routine again after state was advanced to "idle".
Extend the 'state' tracking while we are here, mark sample download as
well (that was omitted in the previous implementation). Though the
omission was non-fatal. Move the release of 'dram_line' to some earlier
location (as soon as the resource is not needed any longer), before some
rather complex calls to other routines will execute.
Reported-By: Michael Kaplan <M.KAPLAN@evva.com>
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 makes the code more consistent with the rest of the code-base
and also allows std_gvar_min_max_step_array() to work here.
Without this change:
src/hardware/scpi-pps/api.c: In function ‘config_list’:
src/hardware/scpi-pps/api.c:570:40: warning: passing argument 1 of ‘std_gvar_min_max_step_array’ from incompatible pointer type [-Wincompatible-pointer-types]
*data = std_gvar_min_max_step_array(ch_spec->voltage);
^~~~~~~
In file included from src/scpi.h:30:0,
from src/hardware/scpi-pps/api.c:23:
src/libsigrok-internal.h:964:19: note: expected ‘const double *’ but argument is of type ‘const float *’
SR_PRIV GVariant *std_gvar_min_max_step_array(const double a[3]);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
src/hardware/scpi-pps/api.c:573:40: warning: passing argument 1 of ‘std_gvar_min_max_step_array’ from incompatible pointer type [-Wincompatible-pointer-types]
*data = std_gvar_min_max_step_array(ch_spec->frequency);
^~~~~~~
In file included from src/scpi.h:30:0,
from src/hardware/scpi-pps/api.c:23:
src/libsigrok-internal.h:964:19: note: expected ‘const double *’ but argument is of type ‘const float *’
SR_PRIV GVariant *std_gvar_min_max_step_array(const double a[3]);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
src/hardware/scpi-pps/api.c:576:40: warning: passing argument 1 of ‘std_gvar_min_max_step_array’ from incompatible pointer type [-Wincompatible-pointer-types]
*data = std_gvar_min_max_step_array(ch_spec->current);
^~~~~~~
In file included from src/scpi.h:30:0,
from src/hardware/scpi-pps/api.c:23:
src/libsigrok-internal.h:964:19: note: expected ‘const double *’ but argument is of type ‘const float *’
SR_PRIV GVariant *std_gvar_min_max_step_array(const double a[3]);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
The HW simply stops sending data on overflows, so if we receive no data
in one second, we abort the acquisition. We also need to allocate more
buffers to support higher sample rates.
Until now, clear_helper() callbacks for std_dev_clear_with_callback()
were expected to g_free(devc), but not all of them did that.
Have std_dev_clear_with_callback() unconditionally g_free(sdi->priv)
(i.e., devc), regardless of whether a clear_helper() callback was
provided or not. It was doing g_free(sdi->priv) when no callback
was provided already anyway.
This makes the individual drivers' clear_helper() implementations
shorter and prevents errors such as missing g_free(devc) calls.
This works, because all drivers either call std_dev_clear_with_callback()
directly, or indirectly via std_dev_clear().
This also allows us to remove some no-longer needed dev_clear()
and clear_helper() implementations that only did g_free(devc)
in favor of std_dev_clear().
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().
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
- sr_dev_clear(): Don't try to clear uninitialized drivers (the same
check was previously done in std_dev_clear()).
- Document some places where we intentionally don't emit log messages.
- std: Various Doxygen fixes and updates.
- std: Add some more sanity-checks on input parameters.
src/hardware/saleae-logic-pro/protocol.c:389:12: warning: 'set_led' defined but not used [-Wunused-function]
static int set_led(const struct sr_dev_inst *sdi, uint8_t r, uint8_t g, uint8_t b)
^
CC src/hardware/saleae-logic-pro/api.lo
src/hardware/saleae-logic-pro/api.c: In function 'dev_acquisition_handle':
src/hardware/saleae-logic-pro/api.c:332:9: warning: missing initializer for field 'tv_sec' of 'struct timeval' [-Wmissing-field-initializers]
struct timeval tv = {};
^
In file included from /usr/include/x86_64-linux-gnu/sys/time.h:27:0,
from include/libsigrok/libsigrok.h:24,
from src/hardware/saleae-logic-pro/protocol.h:25,
from src/hardware/saleae-logic-pro/api.c:23:
/usr/include/x86_64-linux-gnu/bits/time.h:32:14: note: 'tv_sec' declared here
__time_t tv_sec; /* Seconds. */
^
The asix-sigma driver was reported to fail in combination with newer
libftdi versions, because the firmware upload routine opened again an
already opened device, and then failed to claim the interface. Which was
not fatal before with previous libftdi versions.
Remove the redundant open call. Remove the local FTDI context variable,
which brings the firmware upload routine in line with all other calls
that communicate to the USB device.
This fixes bug #471.
Suggested-By: Marian Cingel <cingel.marian@gmail.com>
The asix-sigma driver supports different samplerates, which will involve
different firmware images and will affect the number of available logic
channels as well as their memory layout in downloaded sample data.
Make sure to only store the configuration's parameters after the setup
of that configuration has successfully completed, and make sure to store
a consistent set of parameters. Specifically don't change the number of
channels when the firmware upload failed.
This fixes part of bug #471.
Suggested-By: Marian Cingel <cingel.marian@gmail.com>
The firmware upload code paths in the asix-sigma driver used to return
either the SR_OK code, or the magic number 0 for error conditions. Which
happens to be identical and cannot be told apart by callers.
Provide proper SR_ERR return codes for error conditions, such that
callers can tell whether the firmware upload succeeded.
This fixes part of bug #471.
Suggested-By: Marian Cingel <cingel.marian@gmail.com>
Adjust the string to boolean conversion for an edge case. Accept empty
text (either NULL or empty strings) to mean true instead of false.
This behaviour is more useful from the user's point of view, when the
option's name alone will enable a feature, and an explicit "option=yes"
specification is not strictly necessary. All calling applications in
mainline already implemented this semantics.
Split the data type detection from the actual data type conversion in
the ConfigKey::parse_string() method. Allow the Option class to re-use
the public ConfigKey method, to share the maximum amount of data type
conversion code for both Driver and InputFormat option specs.
This is the least intrusive yet most reliable and consistent approach in
the libsigrok C++ binding that allows applications to support driver scan
and input file format options from command line arguments.
../src/hardware/hung-chang-dso-2100/api.c: In function ‘config_commit’:
../src/hardware/hung-chang-dso-2100/api.c:562:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
state = 0x01;
~~~~~~^~~~~~
../src/hardware/hung-chang-dso-2100/api.c:563:2: note: here
default:
^~~~~~~
../src/hardware/hung-chang-dso-2100/api.c:565:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
if (ret != SR_OK)
^
../src/hardware/hung-chang-dso-2100/api.c:567:2: note: here
case 0x01:
^~~~
../src/output/csv.c: In function ‘receive’:
../src/output/csv.c:580:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
*out = g_string_new(ctx->frame);
~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
../src/output/csv.c:582:2: note: here
case SR_DF_END:
^~~~
../src/input/wav.c: In function ‘send_chunk’:
../src/input/wav.c:200:2: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
memset(fdata, 0, CHUNK_SIZE);
^~~~~~
../src/input/raw_analog.c: In function ‘init’:
../src/input/raw_analog.c:133:31: warning: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 6 [-Wformat-truncation=]
snprintf(channelname, 8, "CH%d", i + 1);
^~
../src/input/raw_analog.c:133:28: note: directive argument in the range [1, 2147483647]
snprintf(channelname, 8, "CH%d", i + 1);
^~~~~~
../src/input/raw_analog.c:133:3: note: ‘snprintf’ output between 4 and 13 bytes into a destination of size 8
snprintf(channelname, 8, "CH%d", i + 1);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
Before firmware upload some models (e.g. the original DSLogic or the
DSLogic Pro) don't have any USB manufacturer or product strings set, so
they wouldn't be detected.
Previously the USB communication code was split between api.ci,
dslogic.c and protocol.c, with protocol internals split between
both. This patch puts all the protocol handling code into one
source file reducing the number of internal interfaces and making
the code more readable.
Previously the USB communication code was split between api.c
and protocol.c, with protocol internals split between both. This
patch puts all the protocol handling code into one source file
reducing the number of internal interfaces and making the code
more readable.
The last release (0.4.0) had the libtool version (current:revision:age)
set to 3:0:0. Since this release adds, removes, and changes interfaces,
the new version is 4:0:0.
http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info
This changes the library filename (e.g. on Linux) from libsigrok.so.3.0.0
to libsigrok.so.4.0.0, the SONAME (+symlink) becomes libsigrok.so.4.
File template by Stefan Brüns, thanks!
This fixes bug #857.
(the XML file is moved from PulseView to libsigrok since this is not
PulseView-specific)
Add a 48x48 PNG and a scalable SVG for the MIME type as well.
Install the XML file and in the icons in the respective standard paths.
This is more specific and prevents any potential issues e.g. when
multiple distro packages might ship with a generic file like
sigrok-logo-notext.png that's supposed to be installed in the same place.
The Input::send() method allocated glib strings and copied input data,
but only released the glib string container and leaked the actual string
content. This led to leaks in the size of the verbatim input file, which
is especially wasteful for uncompressed textual representations.
This fixes bug #976.
When the processing of columns of text lines detected errors, the loop
was aborted and the routine was left, but allocated resources were not
freed. Fix the remaining memory leaks in the error code paths.
The constant at the top of the source file is the number of samples in a
datafeed submission chunk. The previous implementation erroneously made
it the size in bytes. There is no need to round down the buffer size
according to the unit size.
The previous implementation sent one sigrok session datafeed packet per
processed CSV line. This is rather inefficient for the CSV input module,
and triggers a dramatic performance loss in the srzip output format.
Communicate up to 128K samples within one datafeed packet. This fixes
bug #695.
Factor out repeated calculation of the unit size which is derived from
the channel count. Fix a minor memory leak in an error path while we are
here. (Other memory leaks in rare error paths remain with this commit.)
Suggested-By: Elias Oenal <sigrok@eliasoenal.com>
On the Windows platform it appears to be popular to _not_ terminate the
very last line in a text file. Which results in an unmet constraint in
the CSV input module and an internal exception in PulseView which aborts
program execution.
Cope with the absence of the text line termination sequence at the very
end of the input stream. Keep all other checks in place, such that only
completely received text lines get processed.
This fixes bug #635.
"Document" the current state of the implementation in the CSV input
module's source code. Discuss how text handling is non-trivial, which
approaches are available and how they have drawbacks.
Mention the lack of support for the import of analog data as well.
The CSV input module supports variable length end-of-line encodings
(either CRLF, or CR, or LF). When a bunch of accumulated text lines got
processed, do skip the corresponding number of characters after the end
of the last processed line.
This fixes one of the issues discussed in bug #635.
The input module runs receive() and end() invocations which end up
calling process_buffer(). It's perfectly legal to call the process
routine with an empty accumulation buffer, especially when the process
routine was called from end().
This fixes a condition where PulseView raised a fatal error at the end
of a completed successful import.
Reported-By: Sergey Alirzaev <zl29ah@gmail.com>
Move an independent test for single/multi column operation out of a code
path that checked for and then processed text lines. This commit does
not change behaviour, but prepares a subsequent commit.
Factor out a magic string literal which held a delimiter set yet could
be mistaken for an (assumed) fixed termination string. Concentrate the
determination of the end-of-line text encoding as well as the resulting
set of possible deliminters in one nearby location. The symbolic name
for the delimiter set eliminates the doubt on its purpose.
Change uninstall-local to uninstall-hook, since the latter is guaranteed
to run last (order is apparently not guaranteed for uninstall-local).
This fixes bug #861.
Handle the case when the sample data memory was filled and has wrapped
around during acquisition. Download the respective part of the data
which is reliably available, only skipping a single 1KB row which might
contain either old or new data while it's not certain which it would be.
This will be essential when triggers later become available. Right now
it copes with user requests for sample counts that exceed the total DRAM
capacity. Instead the maximum available amount of data is provided.
Of course acquisition no longer gets stopped when the end of DRAM is
reached.
Correctly determine the size of a download chunk for the last DRAM row
that's involved in the recent data acquisition.
This commit is based on work done by jry@.
This addresses bug #838 (trailing garbage).
It's assumed that the previously downloaded excess data was "swallowed"
by the sample count enforcement logic that was applied earlier, so the
(remainder of the) issue could have gone unnoticed, unless some other
termination condition than sample count was used.
Configure the samplerate clock and channel count during acquisition
start in identical ways for 50MHz, 100MHz, and 200MHz modes.
This part was inspired by work done by jry@ yet was addressed in
different ways (no exception, do everything in every mode the same way).
Eliminate a portability issue in the previous implementation. Make sure
to send the configuration bytes in the correct order to the hardware.
Don't typecase a struct reference to a bytepointer and hope that the
internal memory representation might fit the external hardware's idea.
Add a comment about sample memory organization in a central spot. This
concentrates knowledge which otherwise would be spread across several
locations all over the driver's codebase, yet is essential to have at
hand during maintenance.
All of the information was determined/updated by jry@ with the help of
Ondrej at Asix when he did lots of fixes and improvements to asix-sigma.
The Asix Sigma hardware does not support a sample count limit. Instead
this optional input parameter gets mapped to a sample time, and some
slack for hardware pipelines and compression gets added. When data
acquisition completes and sample data gets downloaded, chances are that
there is more data than requested by the user.
Do enforce the optional sample count limit. Stop sending data to the
sigrok session when the configured number of samples was sent.
This commit is based on work done by jry@.
This fixes bug #838.
Enhance how the data acquisition is stopped. Wait for the hardware to
flag the successful completion of data retrieval as well as flushing
through hardware pipelines.
Use symbolic identifiers for the mode register's fields (for read as
well as write access).
This commit uses part of a code update to better match the documentation
done by jry@, but not all of it to reduce the size of the commit.
Minor adjustment for improved readability. Don't hide assignments in
variable declarations. Move initialization of some variables closer to
related evaluation or subsequent processing. Break a complicated looking
roundup expression into several short steps.
Fix how the READ_ID register index was passed to the hardware access.
Addresses are sent in nibbles, so shift by eight is wrong here. No harm
was done, as the register's index is zero.
The Asix Sigma driver is aware of three firmware images, which are
required for acquisition with up to 50MHz, 100MHz, and 200MHz. The
previous implementation always downloaded the corresponding firmware
image whenever the sample rate has changed, which was redundant.
Skip the download when the new samplerate uses the same firmware as the
previously selected samplerate did. This results in faster responses in
the GUI when the samplerate selection changes.
Move assignments out of the variable declaration block for improved
readability while we are here.
The hardware provides captured data at a maximum rate of 16bits per 20ns
(50 MHz). For samplerates of 100 and 200 MHz one individual 16bit entity
contains multiple samples for a reduced number of channels. The bits of
several sample points are interleaved within the 16bit entity.
This commit is based on work done by jry@ who fixed a lot of issues with
the help from Ondrej at Asix.
This fixes bug #840.
Adjust the interpretation of acquired sample data such that regardless
of 50/100/200MHz samplerate the assignment of LA pins to sigrok channels
remains stable.
Introduce helper routines to access the sample data that is provided by
the ASIX hardware, as well as the buffer which accumulates logic data
before it gets sent to the session's datafeed.
This hides endianess issues from call sites, and prepares access to
memory layout which varies with sample frequencies.
This commit is based on work done by jry@.
This works around bug #359. Triggers currently are not operational for
Asix Sigma. Don't claim support in the driver so that UIs won't use the
feature. Yet allow research in this issue, by concentrating the switch
for the feature's support in a central location.
Add/update a comment and unobfuscate an error code path while we are here.
Both the .c and the .h file declared the same identifiers for USB
properties of ASIX hardware with identical values. Remove the .c
incarnation and keep the .h content, as the names are used in api.c
as well as protocol.c sources.
Introduce a separate routine which maps sample counts and sample period
to an elapsed sample time after which acquisition shall get stopped.
Add some more time to make sure the most recent captured data has passed
the hardware pipeline and is available for download.
This commit is based on work done by jry@.
When "tsdiff < EVENTS_PER_CLUSTER" we don't want "tsdiff - EVENTS_PER_CLUSTER"
(a negative number) to be treated as (int).
Submitted-By: jry <jrysig@gmail.com>
[ gsi: massaged for mainline submission ]
The resistance values of some DMMs were incorrectly reported due to a
missing factor of 10 in the calculations.
Tested on Voltcraft VC-920/VC-940 and Tenma 72-9380A/72-7730/72-7732.
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.
Old:
ut71x: Applying exponent -12, new value is 0.000000.
P1: 1.500 nF AUTO
P1: 1.500 nF AUTO
New:
ut71x: Applying exponent -12, new value is 1.5e-09.
P1: 1.500 nF AUTO
P1: 1.500 nF AUTO
This fixes bug #700.
This is a (hopefully temporary) workaround for the
SR_CONF_CAPTUREFILE mechanism. The value for
vdev->capturefile is set by this, however only once
via stream_session_data().
During stream processing in stream_session_data(),
capturefile may receive new values - e.g. when there
are multiple logic files or if there is analog data.
With that, the initially set capturefile is overwritten.
When re-loading the file, we are then running into
issues because we don't know what the initial value was.
As all .sr files use "logic-1" by default and, we
simulate the behavior of stream_session_data() and
assign this name to capturefile if there are logic
channels present.
With this change, all three kinds of files reload
as expected: logic only, analog only and mixed signal.
For this reason, it's a short-term fix for #944.
The handling of the digital channels for this series is somewhere
between that of the DS1000D series (PROTOCOL_V2) and the MSO1000Z
(PROTOCOL_V4).
The :LA command set is similar to that of V4, but the LA data has to be
requested with :WAV:SOUR:LA and arrives in interleaved form like V2.
None of these changes should affect other models. They only affect the
case of PROTOCOL_V3 with digital channels, which occurs only for the
MSO2000A series.
'i' was iterating in steps of unitsize. However, the destination array
was also indexed with it, but it is of u8 type. Let 'i' run bytewise and
only multiply with unitsize when we need it.
This fixes parts of bug #844.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
'j' is the loop variable for channels, not 'i'.
This fixes parts of bug #844.
Reported-by: Maxim Sloyko <m.sloyko@gmail.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
src/output/csv.c: In function 'dump_saved_values':
src/output/csv.c:461:6: warning: format '%lu' expects argument of
type 'long unsigned int', but argument 3 has type 'uint64_t' [-Wformat=]
ctx->sample_time, ctx->value);
^
Fixes#933.
We'd already had this problem elsewhere and thus have this wrapper function
that does this where necessary. It just wasn't in use on these two call sites,
which was causing timing problems when used over tcp-raw or VXI transports.
With trigger enabled, and with PulseView, a second (or more) acquisition
starts immediately instead of blocking. It's mandatory to try several times
to have a correct behavior.
According to http://mygizmos.org/ols/Logic-Sniffer-FPGA-Spec.pdf section 2.3.1
p.8, the Openbench Logic Sniffer must be reset before each arm command.
This fixes bug #809.
Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
Openbench Logic Sniffer reset is a little more complex than a simple send.
To avoid code duplication, this patch adds a new function dedicated to
this task.
Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
Instead of replacing the group=plugdev, simply add the TAG as well.
This allows (in most cases) the same file to be used happily on systemd
and older group based systems. Some systems may produce warnings about
non-existant groups, but it remains functional. Approach inspired by
that taken by the OpenOCD project.
This fixes parts of bug #665.
Signed-off-by: Karl Palsson <karlp@tweak.net.au>
Increasing the chunk size from 512ksamples to 4Msamples leads to
slightly faster session file loading from sigrok session (*.sr) files
in frontends, while not looking too "chunky".
The performance increase is not really massive, but still noticeable.
A further increase to, say, 10 or 100Msamples shows no further
noticeable improvements.
This changes the fx2lafw code to only enable the wide_sampling (16bit)
method, if at least one of the higher eight channels is enabled. This
has the benefit, that we can use higher samplerates on 16bit LA
devices if we use only the first eight channels.
The wide sampling is also enabled if we have one or more analog
channels.
Signed-off-by: Jan Losinski <losinski@wh2.tu-dresden.de>
I've seen the following output from sigrok-cli:
CH1: 478.720 mV
CH1: -514 mV
CH1: -0 V
I added some debug, and it seems like the digits value isn't reset
to the actual value after calling sr_analog_si_prefix_friendly():
using 6 digits
value2 0.478720 digits 6
value2 -0.513536 digits 3
value2 -0.487424 digits 0
This commit fixes this by resetting the value to the actual value before.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
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>
It appears that the symmetry changes of setting CC and CFLAGS correctly
for C code compilation in commit 104f02f broke things for people using
some other version of setuptools which uses those vars instead of
CXX and CXXFLAGS when compiling C++ code. In order to make this work
everywhere, set _both_ sets of variables as required for C++ compilation.
No C code is compiled by the python binding module anyway.
When using SCPI over serial (over USB), we want the header without waiting
for the terminating newline, as otherwise the transfer may time out.
sr_scpi_get_data() will block until the message is complete.
Lowlevel access functions should not alter the data. sr_scpi_get_string(),
which is called by most highlevel access functions, strips newlines
in a central place, and is only fed with data which contains newlines
as a final terminator.
IEEE 488.2 definite length blocks may contain arbitrary data, thus the
payload up to the provided length should be passed unaltered.
Track if the last received character is a newline, which can be used
by sr_scpi_get_string() and its callers to determine if the response
is complete.
g_get_monotonic_time() returns current time in microseconds, use the same
granularity for storing the read timeout.
There is also no need to check the timeout if data has just been read.
sr_period_string takes the frequency as its argument, i.e. the reciprocal
of the timebase. Obviously this will not work for frequencies less than
1Hz / timebases greater than 1 second, but at least is correct for all
other available timebases.
sr_period_string takes the frequency as its argument, i.e. the reciprocal
of the timebase. Obviously this will not work for frequencies less than
1Hz / timebases greater than 1 second, but at least is correct for all
other available timebases.
The output was wrong for all frequencies but 1 Hz, 1 kHz, 1 MHz and 1 GHz.
With this changes, the output may still be off due to rounding, but will
be correct as to the shown accuracy.
When nothing was received in a read attempt, we need not adjust the
buffered data's read position nor the glib string object's size. Skip
any processing for empty input, just keep checking for timeouts.
Routine sr_scpi_get_data() checks for free space in the receive buffer,
and resizes the buffer when free space drops below a threshold. The
previous logic assumed that the resize and the read logic would interact
in some specific way to achieve the desired operation.
Adjust the buffer resize such that more free space is pre-allocated, yet
the payload size of the buffer is not affected. This eliminates the
dependency of the optional resize logic from subsequent activity for
reception of data that is non-optional.
Add comments while we are here, outline the steps taken in the
sr_scpi_get_data() routine.
Phrase the logic which checks the use of analog channels and digital
pods in more generic terms. Place a comment about the contraints' being
potentially dependent on the specific HMO model. This implementation
should lend itself better to future adjustment (HMO1002?).
An internal libsigrok implementation detail prevents partial submission
of logic data for different channel groups in multiple calls. Instead
one logic packet needs to be sent in a single call, which combines data
for all channels.
Introduce a logic data storage which folds samples from several channel
groups that were received at different points in time into a combined
memory layout of larger unitsize. Stick with the former shortcut of
passing on the input bytes directly when only the first digital pod is
used during acquisition.
This change correctly maps data from the second pod to channels D8-D15.
The previous implementation only added one of the digital channels to
the list of enabled channels that are involved in the acquisition (the
first one that was found). This means that when the set of used digital
channels spans more than one pod/group, the second pod will never be
read from.
Make sure to enable one digital channel per pod/group, such that
acquisition will retrieve data from all involved input sources.
Add comments while we are here. Mention how the different setup, check,
start, and receive routines which are spread across several files do
interact to achieve acquisition.
The previous implementation used to put FRAME_BEGIN and FRAME_END
markers around each received chunk of samples, while those chunks
correspond to a single channel (analog) or a group of eight channels
(digital) each. In other words, the hameg-hmo driver had provided a
multiple of the requested frames, and those frames were incomplete.
Make sure to only send FRAME_BEGIN before the first channel's data,
and FRAME_END after the last channel's data of a frame. Thus make
sigrok frames exactly match the scope's frames.
Add some comments on the frame marker and the acquisition stop logic
while we are here.
Configure the scope to the host's native endianess before downloading
acquisition data from analog channels. This unbreaks operation on those
models which default to a representation which differs from the host.
Undo the change which skips management activities when no data was
received. This change breaks the current implementation, and needs to
get deferred until a delicate interaction between the resize and the
read logic has been eliminated.
Replace a C library strcspn(3) call with the more portable glib
g_strstr_len(3) routine. This is possible since a single separator
is searched for, no actual "set of characters" is involved.
As a byproduct, this eliminates a "late" reference to 'cnt' at the
bottom of the routine, after the value was assigned in a rather distant
location at the top of the routine. The cost of strlen() should be
acceptable for a buffer with a single digit total length.
Replace C language string operations with their glib incarnations for
improved portability. Prefer a common sigrok float conversion routine
over a DIY implementation.
The specific packet layout puts constraints on the parse logic (case
sensitive comparison, order of comparison). Fix a comment that made no
sense before, and better reflect that there are two constraints.
Slightly rephrase the SCPI code which parses the responses that carry
(binary) data blocks. Be explicit about NUL termination when parsing the
leading length spec in the response, obsoleting the array initializer.
Add lots of comments and group source code lines to better reflect
what's happening from the protocol's perspective.
Fix the returned error code in the path which reads responses of
excessive length in chunks. The previous implementation detected errors
but always returned code 0 (success).
When nothing was received in a read attempt, we need not adjust the
buffered data's read position nor the glib string object's size. Skip
any processing for empty input, just keep checking for timeouts.
Drop an initial assignment to a variable which never takes effect.
Add braces around the body of a more complex if block. Separate routines
from each other by exactly one empty line.
When the channel state is retrieved, query the pre-set byteorder for
SCPI data blocks as well. When samples get retrieved during capture,
support float representations in either big or little endian format.
This commit unbreaks devices which operate in BE format by default
(tested with HMO2524). It keeps working with LE format as before. For
devices which don't support the byteorder query or return unknown
responses, LE format is assumed for backwards compatibility. The
device's byteorder is only queried and never set. This makes the
commit least intrusive.
A comment mentioned that the models HMO2524 and above support 16 digital
channels (and thus have two pods for the probes). Move those models to a
section that declares the respective features, including trigger support
on the upper digital channels.
Model detection and reflection of supported channels was tested on HMO2524.
Commit db81fbb582 made sure to release a potentially previously
allocated list of enabled channels before (re-)building the list in the
current invocation of acquisition start.
This commit frees the memory in the error path near the failed creation
already, which reduces the period of time where unused resources are
held, and eliminates a memory leak when acquisition is not stopped after
failed start.
Both approaches can coexist. Freeing an empty list is perfectly fine.
Fix the code which registers the name of the second pod for digital
probes. The previous implementation registered the first pod twice, and
lost the reference to the second pod. No harm was done, none of the
supported models declared support for two pods so far.
Factor out a channel to group mapping in the registration of digital
channels, while we are here.
The former DER EE DE-5000 driver was a very thin wrapper around the
ES51919 LCR meter chipset. None of its source was specific to the
deree-de5000 device. In fact it contained code for all currently
supported LCR meters, and it's expected that all LCR meters which
will get added in the future will fit in as well.
Follow the serial-dmm model. Rename the src/hardware/deree-de5000/
directory to serial-lcr/. Update the configure logic. Although the
source directory and the configure option are named serial-lcr, the
LCR meter still is used by specifying the "deree-de5000" device driver
(which just happens to reside in the serial-lcr driver sources, among
others).
Introduce an asycii.c source file (modelled after metex14.c) which
implements support for the 16-byte protocol of the ASYC-II multimeter
chipset (RX only, when the PRINT button was pressed).
Buildsystem wants CXX to be defined as $(CXX).
Otherwise it fallbacks to default value, which does not contain
"-std=c++11" statement.
Other changes (like CC=$(CC) and CFLAGS=$(CFLAGS) instead of CXX ones)
is not directly fix the issue, but fix cases, where CFLAGS (and CC)
differs from CXX* ones, so it could lead to similar errors in the future.
The "deree-de5000" driver is a very thin wrapper around the ES51919
chipset. We expect more models from other vendors to use that same
support code.
Model the registration of vendor/model combinations after the serial-dmm
approach. Register the DER EE DE-5000 device as the currently only
member in a list of drivers which all use the ES51919 chipset (no model
specific routines are registered in the absence of support for other LCR
meter chips).
This commit does not change the driver's behaviour nor the set of
supported hardware. It prepares the addition of more drivers in the
future.
Factor out identical comments on the UART bitrate of ES519xx based
multimeters. These probably got copied from the first item as of 2012
when new items were added in 2014 (the added devices were from the
same vendor and rebadged).
Expand on the fact that the bitrate still is within spec, and does not
harm at all. Strictly speaking the comment could get dropped.
The previous implementation seems to have added drivers in their "order
of appearance". Start sorting the rather long list, to simplify several
tasks: Add new entries as more drivers get written, find existing items
during research, identify and compare similar models during maintenance.
As a byproduct, there will be no doubt about where to put things during
future work :) and duplicates will be spotted immediately.
This commit puts 'bm25x' meters into one group. And comments on the sort
order and motivation for sorting the table.
Commit 6bcb3ee876 introduced initial support for the Cyrustek ES51919
chipset. Its setup_channels() routine used to init a variable to assume
failure, then a loop added channels and changed the value to success.
Commit 5e23fcab88 changed channel setup to never fail, but kept the
initialization with an error code. Which prevented the operation of
successfully detected LCR meters.
Remove the no longer needed variable, instead always return success from
an operation which cannot fail.
Fixes: 5e23fcab88 "Simplify channel creation."
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
Add another DMM entry for Peaktech-3330, which is based on the FS9721
chipset. Support was tested with the CP210x based USB cable.
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
Since tastes and requirements might differ, introduce support for a
user specified character set in the construction of ASCII art graphs
of signal levels. The syntax is "charset=<low><high>[<fall><rise>]",
the default remains backwards compatible with existing consumers.
In comparison to assuming a fixed character set, this change addresses
several distinct aspects:
Users can adjust the output for "higher visual contrast", or "straight
lines" instead of dotted patterns, or "increased difference in height"
for low and high signal levels, or "filled" (block like, "wall of text")
appearance of periods with high levels. User adjustable characters are
needed, as no single fixed set can satisfy the differing expectations.
Perception of the output heavily depends on specific terminals and fonts
in use.
Then there is the issue of levels versus edges, and how their timing
relates. By default edges are drawn at a point in time where the signal
was sampled and was deteremined to already _have_ changed and have
settled to the new level, which means that the position of edges in the
resulting graph might be off by up to one sample period. Strictly
speaking, the available set of samples only contains levels, and does
not hint where exactly an edge might have occured. Though this might be
considered rather nitpicky, representing the graph without edges does
better reflect the input data, and might simplify postprocessing.
Compare the previously only supported format (still the default, -O ascii):
1:...................................................../""""""""""""""""""""
1:""""""""""""""""""""""""""""""""\.........................................
1:..........................................................................
to those example alternatives:
$ sigrok-cli -i file.sr -O ascii:charset=_\"\\/
1:_____________________________________________________/""""""""""""""""""""
1:""""""""""""""""""""""""""""""""\_________________________________________
1:__________________________________________________________________________
$ sigrok-cli -i file.sr -O ascii:charset=_\"
1:_____________________________________________________"""""""""""""""""""""
1:""""""""""""""""""""""""""""""""__________________________________________
1:__________________________________________________________________________
$ sigrok-cli -i file.sr -O ascii:charset=_^
1:_____________________________________________________^^^^^^^^^^^^^^^^^^^^^
1:^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^__________________________________________
1:__________________________________________________________________________
$ sigrok-cli -i file.sr -O ascii:charset=_M
1:_____________________________________________________MMMMMMMMMMMMMMMMMMMMM
1:MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM__________________________________________
1:__________________________________________________________________________
$ sigrok-cli -i file.sr -O ascii:charset=_X
1:_____________________________________________________XXXXXXXXXXXXXXXXXXXXX
1:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX__________________________________________
1:__________________________________________________________________________
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
We now require the use of the latest fx2lafw firmware which uses the
same USB VID/PID (1D50:608E) for the Hantek 6022BE and the variants
and rebadges of that device (e.g. the SainSmart DDS120).
The variants can be distinguished via the USB product version field.
This allows much faster and configurable sampling rate, and faster
reaction to function switch.
This also gives a more repeatable job ordering and more reliable
query/reply association.
The version text length check fails for git setups that use more digits
in abbreviated hashes, as is recommended by e.g. the Linux kernel project.
Raise the upper limit for acceptable version strings, and add comments
on how the limits were determined. The test still might fail in setups
of slightly different configuration, but now it's easier to see why the
test failed, and how to adjust the test.
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
Fix the array size check in the sigma_write_register() routine. The
'len' parameter specifies the number of bytes to write, while the 'buf'
array holds one nibble per array item.
The previous implementation (commit e8686e3ae3) switched to a
constant size and made the buffer large enough so that no existing
request would exceed the buffer, fixing an overflow that was present
before that commit. But the most recent size check was incomplete and
might erroneously succeed for larger amounts of write data.
It's assumed that the issue which gets addressed here never occured in
practice. The constant-size buffer could hold up to 39 bytes of input
data in their transport representation, while the largest data that was
passed to the write routine is six bytes (trigger LUT params).
Fixes: e8686e3ae3 "asix-sigma: Avoid use of variable length arrays"
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
The driver internally implements the "limit samples" feature by means of
the "limit sample period" approach. Determination of the corresponding
period of time for captures depends on the sample rate as well as the
maximum sample count, and thus needs to be re-done when either setting
changes.
Introduce a "limit_samples" variable so that the value is available when
needed later. As a byproduct the parameter can be retrieved now (get).
Add comments to the sigma_set_samplerate() routine's sections, since
quite a bit is happening there, and interacts with other locations.
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
Commit 2c9c0df86e removed the sentinel from the samplerates[] array,
but did not adjust the test which checked whether a rate is listed in
the set of supported rates. This could result in an out-of-range access
beyond the array's last item.
Fix the "listed?" check after iterating the table of supported rates.
Cope with either presence or absence of a sentinel in the array.
Address some more style nits while we are here. Rename an identifier
for a local variable which unintentionally might suggest that it would
be a preprocessor macro (all-caps). Reduce redundancy in data type
references as well as in the determination of the array size.
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
The current implementation of the ASIX Sigma firmware download contains
comments which express uncertainty. Rephrase them, no magic is involved.
Discuss the polarity of the CCLK hardware signal. Which shall eliminate
potential concerns in future reviews or maintenance.
This commit only updates comments, and does not change behaviour.
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
Don't show duplicate lines (per default) such as
sr: resource: Failed to locate 'saleae-logic16-fx2.fw'.
sr: resource: Failed to open resource 'saleae-logic16-fx2.fw'.
The first one is now an sr_dbg() instead of sr_err().
Also, mention that a higher loglevel will give more information as to
where the backend is looking for resources / firmware files.
This fixes bug #806.
This change tweaks the CSV output module to change the label
setting from on/off to units/channels/off, where channels is the old
on behavior, and units uses the meaning field to generate the column
label - except for the generated Time column, which uses the label from
the X axis when it's generating gnuplot output.
- It now handles more than one analog value correctly - at least from the
demo driver.
- Add column headers from channel names.
- Add a row dedup capability.
- Add a sample time column.
- Add a frame end formatting (for gnuplot).
- Made almost all formatting controllable or at least optional.
- Fix it so we can mix analog and digital values.
- Add outputting a gnuplot script for the data.
- Count actual channels, not just mine, to find end of sample.
- Add trigger option (untested).
The default so far was 0, which meant there would be no significant
digits at all, yielding results that looked strange/wrong to the user.
Long-term all remaining drivers should be fixed to use the actual,
correct digits and spec_digits values according to the device's
capabilities and/or datasheet/manual. Until that is done, a default
of digits=2 is used as a temporary workaround.
This fixes the remaining parts of bug #815.
Here's a patch to "Ignore requests to set coupling for the Hantek 6022BE",
this clears the LIBUSB errors for me.
Also in the patch:
- There is a crash because config_list() can be called with sdi == NULL.
This can be reproduced by doing:
"sigrok-cli.exe --driver hantek-6xxx --show"
- There seems to be a very unsafe loop in config_set() when setting COUPLING;
the coupling vector is assumed to be zero terminated, but is not declared
as such.
Note: The same issue is present also for other hardware, at least for
hantek-dso/api.c. The patch is only for hantek-6xxx though.
There were issues when using non-power-of-two data sizes with e.g.
the Hantek 6022BE device. For example, on Windows the acquisition would
simply hang and never complete:
hantek-6xxx: receive_transfer(): status LIBUSB_TRANSFER_ERROR received 0 bytes
The issue was reported by Erik Montnemery on the mailing list, the
original patch was posted by "mmark" here (thanks!):
http://www.eevblog.com/forum/testgear/sainsmart-dds120-usb-oscilloscope-(buudai-bm102)/msg911729/#msg911729
The issue has been verified by me on Windows and Linux, and also that
this change does indeed fix it (tested Hantek 6022BE and Sainsmart DDS120).
Neither PulseView nor sigrok-cli hang anymore on Windows, and on Linux
the log messages suggest improvements as well:
-hantek-6xxx: data_amount 712
+hantek-6xxx: data_amount: 200 (rounded to power of 2: 512)
-hantek-6xxx: receive_transfer(): calculated samplerate == 2327ks/s
-hantek-6xxx: receive_transfer(): status LIBUSB_TRANSFER_OVERFLOW received 512 bytes.
+hantek-6xxx: receive_transfer(): calculated samplerate == 1969ks/s
+hantek-6xxx: receive_transfer(): status LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED received 512 bytes.
This fixes bug #821.
Some functions in std.c were using
const char *prefix = sdi->driver->name;
but were called from input/output modules as well (which don't have
a "driver" field).
As a temporary workaround, use "unknown" as prefix in such cases until
a more permanent solution is implemented.
This fixes bug #813.
This fixes the following build issue on OSX:
Undefined symbols for architecture x86_64:
"_sr_drivers_init", referenced from:
_sr_init in backend.o
This closes bug #802.
When a meter display 105.2 kΩ, libsigrok will return 105200 Ω
but it is really valuable to know that the last 2 digits are not
significant, so encoding.digits should be set to -2.
This would allow a sigrok client to display 105200 as 105.2 k
instead of 105.200 k.
055804e89e changed the outgoing
SCPI message termination by always adding a newline. This results
in the following log output:
sr: [00:00.003102] scpi: Opening VXI device vxi/192.168.178.43.
sr: [00:00.005648] scpi_vxi: Successfully sent SCPI command: '*IDN?
'.
sr: [00:00.005931] scpi: Got response: 'YOKOGAWA,710130,91HC30402,F3.73', length 31.
This patch restores the previous unterminated SCPI message logging:
sr: [00:00.005462] scpi: Opening VXI device vxi/192.168.178.43.
sr: [00:00.007515] scpi_vxi: Successfully sent SCPI command: '*IDN?'.
sr: [00:00.007860] scpi: Got response: 'YOKOGAWA,710130,91HC30402,F3.73', length 31.
As it's located in the general logging mechanism, we deal with any
additional (and unwanted) newlines this way.
This single object also contains the sr_drivers_init function, that will
always be referenced. That ensures that the drivers object files won't
be optimized out during static linking due to the fact that they are
not referenced directly.
This addresses (parts of) bug #802.
These functions were only used in the SR_DF_ANALOG_OLD case,
whereas the SR_DF_ANALOG case already used functions and lists
from src/analog.c.
This closes bug #636.
When config_list() gets NULL as sdi, it must return driver opts.
Some drivers, including zeroplus, don't check sdi and return both
driver opts and device opts.
Now that std_serial_dev_acquisition_stop() has the same signature as
the sr_dev_driver dev_acquisition_stop() callback it is possible to remove
the wrapper functions and use std_serial_dev_acquisition_stop() directly
has the callback function.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
All callers of std_serial_dev_acquisition_stop() currently pass the same
callback for the dev_close_fn parameter as the dev_close callback of their
sr_dev_driver struct. Remove the dev_close_fn parameter and invoke the
drivers dev_close() callback directly. This simplifies the API and ensures
consistent behaviour between different drivers.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
All callers of std_serial_dev_acquisition_stop() currently pass sdi->conn
for the serial parameter. And the other std_serial helper functions already
require that the conn field of the sr_driver_inst passed to the functions
points to the sr_serial_dev_inst associated with the device.
Modify std_serial_dev_acquisition_stop() to follow the same pattern and
remove the serial parameter. This simplifies the API and ensures consistent
behaviour between different drivers.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
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>
All drivers with the exception of pce-322a pass their dev_close callback to
std_serial_dev_acquisition_stop(). The pce-322a passes std_serial_dev_close()
which is also called from its dev_close() callback and replicates the other
functionality of its dev_close() callback directly in
std_serial_dev_acquisition_stop().
Refactor this to pass the dev_close callback function directly to
std_serial_dev_acquisition_stop(). This makes sure that the driver is
consistent with other drivers and also removes duplicated code.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new software limit helper functions rather than open-coding their
functionality.
This also fixes the issue that driver the does not reset all the limit
statistics in acquisition_start().
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new software limit helper functions rather than open-coding their
functionality.
This also fixes the issue that the driver does not reset the limit
statistics in acquisition_start(). It also makes the time limit work, which
previously was only a stub implementation.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new software limit helper functions rather than open-coding their
functionality.
This also fixes the issue that the driver does not reset the limit
statistics in acquisition_start(). It also makes the time limit work, which
previously was only a stub implementation.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The version field in the norma-dmm driver state struct is initialized, but
never read and the same information is also already available in the
sr_dev_inst struct version field. So remove it to simplify the code.
This allows to get rid of the custom dev_close() callback and just use the
standard std_serial_dev_close() instead.
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>
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 link-mso19 driver currently iterates the device instance list of the
driver to get the device instance for which the callback is called.
But the device instance is actually passed to the callback as the cb_data
parameter, so just use that instead and remove the lookup loop.
Besides that the current lookup loop does not even compile either.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The link-mso19 open-codes the std_dev_clear() function and uses it as its
custom dev_clear() callback. The std_dev_clear() function is automatically
called if no custom dev_clear() callback is specified, so just drop custom
implementation and use the default.
This also fixes a memory leak where the link-mso19 driver did not properly
free its driver state struct in the dev_clear() callback.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
sdi is allocated using g_malloc0() which can never fail, in addition to
that sdi is already dereferenced before the check, which makes the check
useless. So remove it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Using "\s*" on BSD sed doesn't work the same way as on GNU sed, thus
yielding e.g. " 3.0.8" instead of "3.0.8" in a ./configure check, which
later prevents the Ruby bindings from being built.
Fix this by simply using exactly one space in the sed invocation, since
swig seems to always use just one space there anyway.
Tested on Mac OS X, FreeBSD, and Linux.
This closes bug #800.
HP instruments predating the 488.2 and SCPI standards do not
necessarily have a SCPI-compliant command set. The HP6630A series of
supplies is one such example.
While scpi-pps is flexible enough to accomodate almost any command
syntax given the right profile, it still assumes that "*IDN?" is the
correct question to ask the instrument. Since older HP gear instead
responds to "ID?", this assumption is no longer true.
Thus sr_scpi_get_hw_id() is not appropriate for these instruments, and
the shadow driver added here only replaces that function call, while
reusing the rest of the existing logic. The extra noise is necessary
in order to propagate this through the .scan member of the driver.
Use the standard connection_id field from the struct sr_dev_inst for
storing the device address rather than using the custom address field in
the driver state struct. This makes things more consistent with the
framework.
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>
Binary block data is specified in IEEE 488.2. First character is '#',
followed by a single ascii digit denoting the the number of digits needed
for the length specification. Length is given in bytes.
This allows drivers to replace retrieval of comma separated ASCII values
with binary formats. See bug #791.
The method accepts strings with numbers in scientific or normal notation,
e.g. -1.25 or 3.37e-6. The numeric range is limited by the sr_rational
range, i.e +-9.2e18, resolution is ~19 digits.
To capture more than 16MSamples the hardware run length encoding option
must be enabled, or captured data present errors.
RLE encoding/decoding is done in hardware. Data streamed to the USB interface
is not encoded.
This commit enables RLE encoding for captures longer than 16MSamples.
Signed-off-by: Diego Asanza <f.asanza@gmail.com>
This commit expands support for acquisition using an external clock,
now allowing the user to select the clock edge.
Signed-off-by: Diego Asanza <f.asanza@gmail.com>
For low sampling speeds (up to 25MHz) DSLogic offers a streaming mode where
samples are sent directly to the USB interface, like a fx2lafw device.
For high sampling speeds (up to 400MHz) only buffer mode is supported.
This commit allows the user to set which mode should be used. The configuration
is done by using SR_CONF_CONTINUOUS.
Signed-off-by: Diego Asanza <f.asanza@gmail.com>
SR_CONF_CONTINUOUS is used to check if a device supports continuous sampling
or not. As such, the type boolean is better suited.
Signed-off-by: Diego Asanza <f.asanza@gmail.com>
The DSLogic provides two FPGA images: one for 3.3V and the other for 5V logic.
The DSLogic Pro allows to set an arbitrary voltage threshold via USB command.
This commit adds support for the DSLogic to load the FPGA image according to
an user-selectable voltage threshold.
For the DSLogic Pro, one of two fixed voltage thresholds are set, depending on
the user-selected value.
Tested with DSLogic and DSLogic Pro.
Signed-off-by: Diego Asanza <f.asanza@gmail.com>
Tested-by: Andrew Bradford <andrew@bradfordembedded.com>
This commit implements DSLogic trigger functionality.
The following triggers are working:
- trigger on rising edge
- trigger on falling edge
- trigger on any edge
- trigger on logic one
- trigger on logic zero
Pre-trigger capture ratio is also working.
Signed-off-by: Diego Asanza <f.asanza@gmail.com>
Tested-by: Andrew Bradford <andrew@bradfordembedded.com>
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>
zip_append_analog() does not free most of the memory it allocates. Address
this by moving all sanity checks that do not rely on anything else at the
beginning of the function before any allocations are done. And then make
sure to properly free all allocated memory on all paths leaving the
function.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
0 is a valid index for a channel. Using it as the value for the terminating
entry of analog_index_map causes zip_append_analog() to falsely assume that
no channel was found when a packet for a channel with index 0 was received.
This prevents the data for the channel to be added to the sigrok session
file.
Instead use -1, which is not a valid channel index, as
the terminating entry value.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The former appended the necessary switch to enable C++11 to the CXXFLAGS
whereas AX_CXX_COMPILE_STDCXX appends it to CXX which has the benefit
that all C++ sources are compiled using the same C++ standard. Therefore
it is no longer necessary to manually hardcode '-std=c++11' anywhere
like we did in the Ruby bindings linker command and assures that the
compilation of them is done with C++11 support as well.
This fixes bug #795
The bindings file was not listed in EXTRA_DIST and therefore not
distributed. We also need to provide an target to uninstall the Ruby
bindings and add it to UNINSTALL_EXTRA in order to make `make distcheck`
happy.
This fixes bug #741
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>
The zeroplus-logic-cube driver uses libusb_get_device_list() but neglects
to call the matching libusb_device_list_free() on the error path. This will
leak the memory allocated for the list as well as all the devices.
To address the issue use sr_usb_open() instead of open-coding its
functionality. sr_usb_open() correctly handles freeing the device list.
The issue was discovered using the following coccinelle semantic patch:
// <smpl>
@@
identifier devlist;
expression ctx, ret;
statement S;
@@
(
libusb_get_device_list(ctx, &devlist);
|
ret = libusb_get_device_list(ctx, &devlist);
if (ret < 0) S
)
... when != libusb_free_device_list(devlist, ...)
*return ...;
// </smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The victor-dmm driver uses libusb_get_device_list() but neglects to call
the matching libusb_device_list_free() on the error path of libusb_open().
This will leak the memory allocated for the list as well as all the
devices.
To address the issue use sr_usb_open() instead of open-coding its
functionality. sr_usb_open() correctly handles freeing the device list.
The issue was discovered using the following coccinelle semantic patch:
// <smpl>
@@
identifier devlist;
expression ctx, ret;
statement S;
@@
(
libusb_get_device_list(ctx, &devlist);
|
ret = libusb_get_device_list(ctx, &devlist);
if (ret < 0) S
)
... when != libusb_free_device_list(devlist, ...)
*return ...;
// </smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The testo driver uses libusb_get_device_list() but neglects to call the
matching libusb_device_list_free() on the error path. This will leak the
memory allocated for the list as well as all the devices.
To address the issue use sr_usb_open() instead of open-coding its
functionality. sr_usb_open() correctly handles freeing the device list.
The issue was discovered using the following coccinelle semantic patch:
// <smpl>
@@
identifier devlist;
expression ctx, ret;
statement S;
@@
(
libusb_get_device_list(ctx, &devlist);
|
ret = libusb_get_device_list(ctx, &devlist);
if (ret < 0) S
)
... when != libusb_free_device_list(devlist, ...)
*return ...;
// </smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
lascar_scan() calls libusb_get_device_list() but never the matching
libusb_free_device_list(). This will leak the memory allocated for the
device list as well as all the devices. To fix this add the missing
libusb_free_device_list().
While we are at it also make sure to handle errors returned by
libusb_get_device_list().
The issue was discovered using the following coccinelle semantic patch:
// <smpl>
@@
identifier devlist;
expression ctx, ret;
statement S;
@@
(
libusb_get_device_list(ctx, &devlist);
|
ret = libusb_get_device_list(ctx, &devlist);
if (ret < 0) S
)
... when != libusb_free_device_list(devlist, ...)
*return ...;
// </smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Some drivers check in some of their driver callbacks if the driver has been
initialized and return an error if it has not.
For the scan() callback the sigrok core checks if the driver has been
initialized and if not returns an error. So it is not possible that the
scan() callback gets called if the driver is not initialized. Without the
scan() callback succeeding it is not possible to get a reference to a
device which is associated with the driver, so it is not possible that any
of the device specific callbacks is called without the driver first being
initialized either.
In conclusion these checks are not necessary since they never evaluate to
true and can be dropped. If they should ever become necessary they should
be done in the sigrok core so all drivers and all callbacks are equally
handled.
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>
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>
Devices for the scpi-pps 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 for the dev_clear() callback. This
will cause memory leaks when sr_dev_clear() is called for this driver.
To fix this let the dev_clear() free the additional data.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Devices for the deree-de5000 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>
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>
When g_file_get_contents() encounters an error a new GError will be
allocated and passed back to the application. The application is
responsible for freeing this GError.
The baylibre-acme driver currently does not do this and as a result leaks
memory during the scan process when no device is found.
Add the missing g_error_free() invocations to fix the issue.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Make sure to free the FTDI device list and the FTDI context in scan_all()
otherwise memory leaks can be observed. Also make sure to free the FTDI
context in scan_device() on the error path.
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.
The USBee AX hardware needs a sampling clock that is lower than
the 30MHz or 48MHz that the FX2 has to offer. This flag will enable
clocking via the CTL2 pin that is an even divisor of the main clock.
The driver did not look at the mq_flags provided with the
SR_CONF_MEASURED_QUANTITY key, and it defaulted to DC measurements.
Use the second member of the tuple provided by the config key, which
represents the flags for the measurement, and set the instrument's
measurement mode accordingly.
On the high-end bench multimeters, resistance can be measured with a
kelvin connection as well as the more common two wire method. Provide
a flag which can indicate if four-wire mode is used.
Due to a PEBKAC error, after the last sample was sent, a new
measurement was triggered, but its value was never sent down the
session bus. This is easily fixed by incrementing devc->num_samples
right after a measurement is sent instead of when a measurement is
retriggered.
g_variant_print() allocates memory during call. Save the pointer
so that it can be free'd afterwards.
==10048== 16 bytes in 1 blocks are definitely lost in loss record 17 of 37
==10048== at 0x4C2DEAE: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10048== by 0x536C85D: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x53877C6: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x5388B60: g_string_append_vprintf (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x5388D83: g_string_append_printf (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x539D034: g_variant_print_string (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x539C92C: g_variant_print (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x4E5F713: log_key (hwdriver.c:597)
==10048== by 0x4E5FCD5: sr_config_set (hwdriver.c:752)
==10048== by 0x408C1A: run_session (session.c:661)
==10048== by 0x404FC5: main (main.c:267)
==10048==
==10048== 16 bytes in 1 blocks are definitely lost in loss record 18 of 37
==10048== at 0x4C2DEAE: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10048== by 0x536C85D: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x53877C6: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x5388B60: g_string_append_vprintf (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x5388D83: g_string_append_printf (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x539D034: g_variant_print_string (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x539C92C: g_variant_print (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x4E5F713: log_key (hwdriver.c:597)
==10048== by 0x4E5FBDD: sr_config_get (hwdriver.c:709)
==10048== by 0x4080D7: datafeed_in (session.c:196)
==10048== by 0x4E5D47E: sr_session_send (session.c:1192)
==10048== by 0x4E62682: std_session_send_df_header (std.c:101)
Using non power of 2 sizes causes the driver to not work on OS X.
Depending on the usb transfer mode the buffer sizes will map
perfectly to the underlying transport protocol.
scpi_serial generate an POLLIN event after the requested data is returned
by the instrument. For USBTMC it is necessary to
1. send an REQUEST_DEV_DEP_MSG_IN request
2. submit an USB bulk read transfer asynchronously.
Using the synchronous libusb_bulk_read() does not generate an POLLIN event.
Solving this properly needs major surgery in spci_usbtmc_libusb.
While some transports add a terminating (carriagereturn+)linefeed
unconditionally, the USBTMC transport does not. At least the R&S HMO1002
requires the linefeed and locks up otherwise. Fixes bug #784.
This changes the TCP and VXI transport from CR+LF to LF only.
Also fixes a possible memory leak for VXI, where the temporary command
buffer was not freed in case of a write error.
According to USBTMC usb488 subclass spec, wValue hast to be 0 for both
LOCAL_LOCKOUT and GO_TO_LOCAL. At least required for R&S HMO1002, the
bad request results in a STALL. Fixes bug #783.
After acquisition start, DSLogic stores samples in memory, and when done it
sends a USB packet with the trigger position.
This initial fillup can take some time. If the user requests a session stop
in between, the USB transfer is cancelled and the session hangs because it
is not closed properly.
This commit manages this case and closes the session properly when
acquisition is stopped by the user.
Signed-off-by: Diego F. Asanza <f.asanza@gmail.com>
According to the infos I have, VCD files should be plain ASCII, but we
got report of a version adding a UTF8 BOM at the beginning of the file,
so we need to skip it.
This fixes bug #755.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
For some reason, uploading the FPGA binary into DSLogic in small chunks
does not work. In this commit, the whole binary image is loaded into memory
and transfer is done in one chunk.
Furthermore, the FPGA configuration structure was not initialized
properly. This was changed with the initialization values taken from the
original DSLogic software.
Signed-off-by: Diego Asanza <f.asanza@gmail.com>
Certain output modules do not understand double-precision data.
Although we need double precision to represent the full resolution
of 7.5 digit readings, temporarily convert data to single precision
so that the output modules understand it. While the reasing might be
off by a few counts, we ensure the output modules do not display
completely bogus data.
For details, see bug #779.
KNOWN ISSUES:
- When sampling with 100 NPLC, the poll function will timeout a few
times before the first sample is acquired. Increasing the timeout
passed to sr_scpi_source_add() will cause all the other commands to
be processed slowly, producing a sampling rate of about one sample
every ten seconds.
- Support for plug-in cards (44491A and 44492A) is not implemented.
- Support for AC, AC+DC and four-wire resistance measurements is not
implemented.
- Support for configuring the frequency measurement source is not
implemented.
High precision multimeters have a special setting, called "number of
powerline cycles" (NPLC) which determines the integration time of the
ADC in terms of the power line period. Some devices need their NPLC
adjusted from the default value before they can measure at their full
rated precision.
Devices connected on a real GPIB bus are placed in remote mode when
opening them. libgpib does not automatically place devices back in
local mode when closing the handle. It is thus possible to lock out a
GPIB device by probing it with libsigrok.
This happens on the HP 3457A meter, which does not have a "LOCAL"
command, and must be put back in local mode via GPIB handshake.
ibloc() takes care of this, and it does it on a per-device basis,
such that other devices on the GPIB bus are not affected.
libgpib has an error_string which formats a numeric error code into a
human-readable description. Use that instead of printing the numeric
code, as it makes debugging easier.
- Don't set capturefile if no logic channels are saved
- Don't set total probes if no logic channels are saved
- Save analog channels without index gaps (e.g. probe1/probe4)
Note: This commit is based on the initial implementation by
Christer Ekholm (but stashed into one commit), with some adaptations
(forward porting, coding style and consistency fixes) by Uwe Hermann.
We want the size of the struct, not of a pointer to the struct. And to
be absolutely future proof, dereference the pointer we are assigning the
memory to (not the one we are copying the data from). Found by Coverity,
CID 50858.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The firmware has "on\n" and "off\n" commands since 1.10, so use them.
Apparently you can only set the state (on/off) of the load, but it's
not possible to query the current state.
Also note that the __ namespace is reserved by POSIX for its private
usage, so user land software should never rely on any kind of API
with a __ prefix.
The last release (0.3.0) had the libtool version (current:revision:age)
set to 2:0:0. Since this release adds, removes, and changes interfaces,
the new version is 3:0:0.
http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info
This changes the library filename (e.g. on Linux) from libsigrok.so.2.0.0
to libsigrok.so.3.0.0, the SONAME (+symlink) becomes libsigrok.so.3.
For session sources without a file descriptor to poll a negative number
should be passed for the fd parameter. The hung-chang-dso-2100 driver
currently passes 0 instead, which is the stdin stream. Fix the issue by
passing -1 for the fd parameter.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Accept (and set to default) 0 for numchannels which means 'unlimited'.
I think it is convenient to read all channels of a vcd file by default.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Benefits:
* only channels really used in vcd will be added
* we can give them the proper name found in the vcd file
* less code :)
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Current code moves the identifier string one byte to the front to
overwrite the bit value, so 'tokens[i]' is a string to compare against
the desired value. This copying is unnecessary, just pass a properly
setup pointer.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
No need to bail out on vectors. As long as there are tokens left, we can
try to parse the rest. Also, print a message so the user knows what's
going on. Here is a testcase vcd:
$timescale 1 ns $end
$var wire 1 n0 addr_0 $end
$var wire 1 n1 addr_1 $end
$enddefinitions $end
#0
0n0
b1 n1
#1
1n0
b0 n1
#2
0n0
b1 n1
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
If we hit the missing identifier case, then we reached the end of the
token list. So, we should break out of the loop, and not continue.
Otherwise we will go past the end of the array as this minimal testcase
shows:
$timescale 1 ns $end
$var wire 1 n0 addr_0 $end
$enddefinitions $end
1
gives:
$ ./sigrok-cli -I vcd -i no_mod.vcd -O vcd -o /tmp/o.vcd
Segmentation fault
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
A $var block can have an optional index item which looks like '[<sth>]'.
Parse it, too, and append it to the channel name.
This fixes bug #322. A first version was posted by Simon Richter. This
version is rebased and simplified.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
As we're downsampling, several record time stamps can match the specified
trigger time. For this reason, it's possible that several trigger packets
are sent when a file is loaded. This prevents the issue and sends a
trigger packet only on the first matching record.
src/hardware/lecroy-logicstudio/protocol.c: In function 'handle_fetch_samples_done':
src/hardware/lecroy-logicstudio/protocol.c:261:3: warning: passing argument 6 of 'libusb_fill_bulk_transfer' from incompatible pointer type
recv_bulk_transfer, (void *)sdi, USB_TIMEOUT_MS);
^
In file included from ./src/libsigrok-internal.h:31:0,
from src/hardware/lecroy-logicstudio/protocol.h:26,
from src/hardware/lecroy-logicstudio/protocol.c:23:
/home/uwe/sr_mingw/include/libusb-1.0/libusb.h:1546:20: note: expected 'libusb_transfer_cb_fn' but argument is of type 'void (*)(struct libusb_transfer *)'
static inline void libusb_fill_bulk_transfer(struct libusb_transfer *transfer,
^
src/hardware/lecroy-logicstudio/protocol.c: In function 'fetch_samples_async':
src/hardware/lecroy-logicstudio/protocol.c:314:4: warning: passing argument 6 of 'write_registers_async' from incompatible pointer type
handle_fetch_samples_done);
^
src/hardware/lecroy-logicstudio/protocol.c:200:12: note: expected 'libusb_transfer_cb_fn' but argument is of type 'void (*)(struct libusb_transfer *)'
static int write_registers_async(const struct sr_dev_inst *sdi,
^
src/hardware/lecroy-logicstudio/protocol.c: In function 'lls_start_acquisition':
src/hardware/lecroy-logicstudio/protocol.c:1122:3: warning: passing argument 6 of 'libusb_fill_interrupt_transfer' from incompatible pointer type
recv_intr_transfer, (void *) sdi, USB_TIMEOUT_MS);
^
In file included from ./src/libsigrok-internal.h:31:0,
from src/hardware/lecroy-logicstudio/protocol.h:26,
from src/hardware/lecroy-logicstudio/protocol.c:23:
/home/uwe/sr_mingw/include/libusb-1.0/libusb.h:1602:20: note: expected 'libusb_transfer_cb_fn' but argument is of type 'void (*)(struct libusb_transfer *)'
static inline void libusb_fill_interrupt_transfer(
^
There is no status bit for RMS. We know about RMS if certain modes are
active. So, drop this superfluous variable.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The primary display is the power factor, the secondary is the frequency.
This got mixed up, so change the order. We also need to fix the
conversion factor.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
is_power_apparent_power is index 0 of function 0x39, so it is better to
process it first and the later indices after that (we need to add
another one with a different patch later).
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Testing showed that AC current needs to be handled different from DC.
Note that ACA is still untested because of limited testing equipment.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
It was confusing to see the display value (5 digits) printed in debug
output as a float. Print it the same way as shown on the real device,
without comma, of course.
This also allows to simplify the code a little.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
This g_close(), the only one in the whole code-base, would unnecessarily
raise the minimum glib version to 2.36.
Thanks to Daniel Glöckner for the report.
This fixes bug #724.
The new methods wrap the new libsigrok C API helper functions and eliminate
the need to pass complex types back to the user and wrap them with SWIG.
Fixes bugs #479 and #480.
This function replaces the pattern of calling config_list() with
SR_CONF_DEVICE_OPTIONS to obtain a list of device options. Note
that this does not include the SR_CONF_{GET,SET,LIST} bitmask,
which is now retrieved for a specific key by calling
sr_dev_config_capabilties().
Refactor handling the size of modbus_devs, so it doesn't produce a build
warning and still allows the compiler to remove unused code.
This fixes bug #637. It could be reverted once modbus_devs
unconditionally has a member in the struct.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
In some situations, the reply to the *IDN? command contains an
additional trailing 0x01 byte for unknown reasons.
This issue seems to be reproducible by changing the voltage using the knobs
on the device, then turning on the output and turning it off again.
The next korad-kaxxxxp scan() operation would contain the trailing 0x01
byte, which would lead to the detection of the device in libsigrok no
longer working until the next power-cycle.
Work around this issue by treating both the ID string with and without
the trailing 0x01 byte as valid.
This is a desperate measure to improve the success rate of device
initialization even after it got into a bad state. Combine this
with a reduced USB timeout (1 second) so that if it fails, it fails
quickly. Also ignore USB errors from the initial dummy read of the
device test ID.
Detect whether the FX2 firmware of the LWLA device exhibits the
short transfer bug. If so, work around the problem by limiting
reads to at most 64 bytes at a time. This slows down the memory
read after acquisition quite noticably, but makes the device
usable even in adverse conditions.
Reduce the number of long registers read in bulk during status
polling from 10 to 5. The LWLA1034 driver used to do that already
in an earlier iteration, which was then changed to be more like
the original vendor software. The reason for bringing it back now
is that it reduces the response size to 40 bytes, which works
around the spurious 64 byte limit bug in the FX2 firmware of the
LWLA devices.
The sr_input_dev_inst_get API documentation guarantees an input is fully
initialized as soon as the device instance is returned. An sdi
implementation should not set sdi_ready any earlier.
This fixes parts of bug #387.
The source file enum.hpp was not found when not building in the source
tree. Also, extraction of the brief description did not work correctly
when there was additional XML markup inside the <para> element.
The sixth character from ISET? is read and discarded. If the device is
turned off and on again, this won't be there and causes 10 ms delay in
every ISET? Luckily, this value isn't queried that often. To get the
sixth byte, the *IDN? command has to be issued before ISET?.
==18779== 800,000 bytes in 196 blocks are definitely lost in loss record 29 of 29
==18779== at 0x4C29110: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18779== by 0x4E635C3: receive (analog.c:319)
==18779== by 0x40870B: datafeed_in (session.c:316)
==18779== by 0x4E59D4E: sr_session_send (session.c:1201)
==18779== by 0x4E59F8B: sr_session_send (session.c:1159)
==18779== by 0x4E62595: send_chunk (wav.c:234)
==18779== by 0x4E62A06: process_buffer (wav.c:290)
==18779== by 0x40954A: load_input_file_module (input.c:123)
==18779== by 0x4097AB: load_input_file (input.c:157)
==18779== by 0x40531E: main (main.c:288)
==17549== 32 (16 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 22 of 39
==17549== at 0x4C29110: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==17549== by 0x5359200: g_malloc (in /usr/lib64/libglib-2.0.so.0.4200.2)
==17549== by 0x536EE2D: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.4200.2)
==17549== by 0x5370165: g_slist_append (in /usr/lib64/libglib-2.0.so.0.4200.2)
==17549== by 0x4E595C3: sr_session_datafeed_callback_add (session.c:512)
==17549== by 0x409527: load_input_file_module (input.c:111)
==17549== by 0x4097AB: load_input_file (input.c:157)
==17549== by 0x40531E: main (main.c:288)
==7478== Invalid write of size 8
==7478== at 0x4E59182: sr_session_dev_remove_all (session.c:302)
==7478== by 0x4E591CD: sr_session_destroy (session.c:265)
==7478== by 0x4095D9: load_input_file_module (input.c:143)
==7478== by 0x4097AB: load_input_file (input.c:157)
==7478== by 0x40531E: main (main.c:288)
==7478== Address 0x7877eb8 is 88 bytes inside a block of size 96 free'd
==7478== at 0x4C2A37C: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7478== by 0x4E5F454: sr_input_free (input.c:573)
==7478== by 0x4095C3: load_input_file_module (input.c:140)
==7478== by 0x4097AB: load_input_file (input.c:157)
==7478== by 0x40531E: main (main.c:288)
Do not use size_t for values whose width is defined by the device,
not the host. Also don't use size_t for simple indices with known
small range, unless type compatibility considerations apply.
Refactor the sysclk-lwla driver to separate the generic logic from
the model-specific implementation. Based on this, implement support
for the SysClk LWLA1016 device.
On some systems it can happen that the USB 'bus' number is a lot larger
than 64, but sr_usb_find() currently errors out if it is > 64.
Example:
Bus 250 Device 006: ID 1ab1:04ce 1ab1 DS1000Z Series[...]
Increase that limit so that the code will work everywhere. This bus number
is queried via libusb_get_bus_number() which returns an uint8_t, so we're
limiting to 255 here.
Thanks to 'ssi' on IRC for reporting the issue.
Apparently (some versions of) Mac OS X have the same problem with
usb_get_port_path() as FreeBSD does. Work around this in the same way.
Thanks to hanyazou@gmail.com for the patch!
This fixes bug #673.
The driver should now be able to cope with e.g. multiple ChronoVu LA8
and/or ChronoVu LA16 devices being connected to the same PC.
It now also provides the serial number and connection ID, which can be
used by frontends to differentiate multiple devices.
Also improve the scanopts / drvopts / devopts lists handling.
This fixes bug #504.
Set both CFLAGS and CXXFLAGS when executing setup.py to build
the Python bindings. Newer versions of distutils/setuptools have
apparently started to pick up the latter when compiling C++.
Check for either Python 2 or Python 3 header files depending on
the version of the Python interpreter. Also require the module
version to exactly match the interpreter version.
This may fix bug #645.
With the current driver API and the corresponding session event
handling, it is not possible to destroy and then re-create an
event source with the same key within the same main loop iteration.
The next generation driver API will fix this problem. But for now,
just change the driver to make do without that sort of thing. Also
increase the I/O timeout to 100 ms to be safer in the event of all
kind of delays the OS environment may induce.
This fixes bug #678.
Evaluate all 64 bit of the duration field in the capture status
record. Although unlikely in practical use, due to compression
it is possible for the duration in ms to exceed 32 bit.
zip_discard() was introduced in libzip 0.11, which some systems
do not have yet. Provide a fallback replacement for zip_discard(),
and reduce the requirement to libzip 0.10 again.
This fixes bug #674.
std::default_delete<> is originally defined as struct, not class.
This does not really make much of a difference, but some compilers
complain when the struct/class tag is not consistent across all
declarations of the type.
Make the Python and Java bindings use the same set of preprocessor
macros for the SWIG parsing stage, taken from a make variable. Add
G_GNUC_{BEGIN,END}_IGNORE_DEPRECATIONS to that set.
During initialization of the LWLA1034, read the 64-bit test word
twice and verify the result of the second read only. This better
matches what the original vendor software does.
Apparently, these four registers form an interface for indirect
access to another internal 64 bit wide memory. This is likely the
same memory as that accessed by the bulk transfer commands 7 and 8.
Added support for SR_CONF_REGULATION which returns value for CH1
Also VELLEMAN LABPS3005D (only device currently supported) sends single
'M' character in beginning of return value, which is specially discarded.
Writing to an object through a pointer of incompatible type is
really evil. Even when the data size matches, it is still a
violation of strict aliasing rules.
Replace all instances by direct casts of the value, without the
unnecessary and dangerous indirection.
The Java bindings currently have some weird problem with function
arguments passed by const reference. Not all types are affected,
but the collection types that involve custom typemaps are.
For now, revert back to pass-by-value for the problematic types.
Looks like SWIG silently ignores default arguments specified via
aggregate initialization. This is rather unfortunate, especially
if the argument types are complex.
Replace custom Deleter classes with std::default_delete<>, declared
as friend so it can invoke the private destructor. Inexplicably,
std::shared_ptr<> does not use default_delete<> by default, so it
is still necessary to explicitly specify the deleter when creating
shared_ptr instances.
With this, unique_ptr and shared_ptr instances now use the same
default delete mechanism.
Make use of std::unique_ptr<> to manage the lifetime of members
or container elements, so that manual invocations of delete can
be avoided. This also provides for exception safety.
Since std::unique_ptr<> is only movable but not copyable, adapt
the code to avoid copies and assignments of these pointers.
Reduce needless over-generalization. There is no design need
for the ParentOwned and UserOwned classes to contain the C base
struct pointer. Instead, just make the _structure pointer a
private member of each class that needs one.
Apparently this problem has been fixed in SWIG 3.0.6. However,
until we can require that version, define "private" as "protected"
when running the SWIG parser.
Declare accessor methods that return value members const. For now,
skip all cases where constness would have to be applied transitively
to shared objects.
Context::package_version() and Context::lib_version() do not access
context state and should be static. However, leave the logging
related methods alone for now, as making them static would entail
making the callback data a global static, since the C API lacks
destroy notification callbacks.
If one of these functions does throw an exception, std::terminate()
will be called. Without this, the behavior is undefined since the C
stack is not prepared to deal with exceptions.
The SWIG 2.0.12 on my system bails out with a syntax error on the
"noexcept" keyword in C++11 code. Define "noexcept" to nothing (for
the SWIG parser only) to work around this problem.
Make use of std::move() to transfer arguments passed in by value.
Take complex container arguments by const reference, as passing
those by value is rather unorthodox even for C++11 style code.
Using the attribute mechanism results in badly named wrappers like
getLog_level(), as well as incompletely applied typemaps for templated
container types. If we just avoid this mechanism entirely, we get the
same foo() and set_foo() accessors as we have in the C++ API.
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.
If we're going to %extend these methods, we need to firstly ignore the
originals, and secondly implement all possible argument combinations.
This fixes the rest of bug #417.
Without this we get:
/usr/include/python2.7/numpy/npy_1_7_deprecated_api.h:15:2: warning: #warning
"Using deprecated NumPy API, disable it by " "#defining NPY_NO_DEPRECATED_API
NPY_1_7_API_VERSION" [-Wcpp]
As far as I'm aware we're not using any deprecated NumPy C API features.
This fixes part of bug #417.
Introduce a new API function sr_session_stopped_callback_set()
which can be used to receive notification when a session stops
running. This allows applications to integrate libsigrok event
processing with their own main loop, instead of blocking in
sr_session_run().
With this driver it is possible to set voltage target and current
limit. Also enabling and disabling the output is possible.
Analog output sends read back values from output. If output is
disabled analog outputs 0.00.
In protocol.c there is a g_usleep() call. This gives almost
every time enough time for PSU to parse and process input.
Multichannel devices aren't supported.
Instead of using a non-standard packed attribute, read the contents of the
probe EEPROM into a buffer and then process it using the R* macros.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Standard integer types may differ in size on different targets. Use fixed-size
types instead.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
The hard-coded location is bound to be wrong anyway. Instead, rely
on the new resource lookup code to find the firmware files in a
location relative to the library or executable.
SR_CONF_NUM_LOGIC_CHANNELS is defined as SR_T_INT32. Create the
GVariant with the correct type to avoid a type mismatch error in
sr_variant_type_check().
The resource API provides a generic means for accessing resources
that are bundled with sigrok, such as device firmware files. Since
the manner of resource bundling is platform-dependent, users of
libsigrok may override the functions used to open, close and read
a resource. The default implementation accesses resources as files
located in one of the XDG data directories or a directory defined
at compile time.
Use in-memory buffers instead of temporary files. This avoids
the need for low-level I/O on the FD returned by g_mkstemp().
Refactor the code accordingly. Also plug a number of leaks and
tighten the error checking.
Completely remove the old session save code that has been
superseded by the srzip output module. Also refactor a bit,
plug a number of leaks and tighten the error checking.
Introduce the sr_file_get_size() utility function to retrieve the
size of an open FILE stream. This is based on fseeko() followed by
ftello(), which are POSIX functions but quite portable in practice.
Since these calls operate on FILE streams instead of filenames, the
issue of filename encoding no longer arises.
Do not use Unix low-level I/O for reading a regular input file.
Read in the file header once and re-use the buffer for all input
modules participating in the scan. Also re-use a prefilled metadata
table instead of creating it anew for each input module tried.
This fixes parts of bug #423.
The list of fixed warnings:
src/output/srzip.c:285:3: warning: Value stored to 'ret' is never read
ret = zip_append(o, logic->data, logic->unitsize, logic->length);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/scpi/scpi.c:610:2: warning: Value stored to 'ret' is never read
ret = SR_OK;
^ ~~~~~
src/scpi/scpi.c:667:2: warning: Value stored to 'ret' is never read
ret = SR_OK;
^ ~~~~~
src/dmm/vc870.c:410:2: warning: Value stored to 'info_local' is never read
info_local = (struct vc870_info *)info;
^ ~~~~~~~~~~~~~~~~~~~~~~~~~
src/hardware/conrad-digi-35-cpu/api.c:130:2: warning: Value stored to 'ret' is never read
ret = SR_OK;
^ ~~~~~
src/hardware/fx2lafw/api.c:658:2: warning: Value stored to 'timeout' is never read
timeout = fx2lafw_get_timeout(devc);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~
src/hardware/gmc-mh-1x-2x/protocol.c:941:3: warning: Value stored to 'retc' is never read
retc = SR_ERR_ARG;
^ ~~~~~~~~~~
src/hardware/gmc-mh-1x-2x/api.c:168:2: warning: Value stored to 'model' is never read
model = METRAHIT_NONE;
^ ~~~~~~~~~~~~~
src/hardware/ikalogic-scanalogic2/api.c:325:2: warning: Value stored to 'ret' is never read
ret = SR_OK;
^ ~~~~~
src/hardware/openbench-logic-sniffer/api.c:185:3: warning: Value stored to 'devc' is never read
devc = sdi->priv;
^ ~~~~~~~~~
src/hardware/rigol-ds/api.c:813:3: warning: Value stored to 'devc' is never read
devc = sdi->priv;
^ ~~~~~~~~~
src/hardware/scpi-pps/api.c:405:2: warning: Value stored to 'ret' is never read
ret = SR_OK;
^ ~~~~~
src/hardware/yokogawa-dlm/api.c:239:2: warning: Value stored to 'ret' is never read
ret = SR_ERR_NA;
^ ~~~~~~~~~
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.
Firmware versions starting with 00.02.04 apparently cause the in and out
bulk endpoints to end up in a HALT state. This is likely related to the
larger transfer size quirk implemented in the Linux kernel for the Rigol
DS1000: this USBTMC implementation does not have that workaround.
Instead, if the firmware version is >= 00.02.04, both endpoints have the HALT
condition cleared on device close.
This fixes bug #354.
The wrong byte was being used to test for the nano indicator.
This resulted in reported resistance and capacitance readings being off
by orders of magnitude.
This fixes bug #657.
The check for p == q is basically checking whether p/q == 1. We should
be normalising the rational before it gets here though, so in this case
we should have p == q == 1 here.
scpi-pps at line 212 assumes that an SR_OK return means that the gvar
is valid, which leads to the following error:
** GLib:ERROR:/build/glib2.0-2.45.8/./glib/gvarianttypeinfo.c:184:g_variant_type_info_check: assertion failed: (0 <= index && index < 24)
GPIO direction should be set once right after exporting. There's no need
to reset it again - in fact it's a bug which causes the probe to be reset
every time the value is read/set and gives incorrect results when reading
the GPIO values with direction == 'in'.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Revision B of ACME hardware introduces probes with on-board at24cs02
EEPROM. Extend the ACME driver to support reading the contents of
the EEPROM via linux' sysfs interface.
Also: make the driver be able to tell the difference between revisions,
add new GPIO layout and set the shunt resistance for revB at probe
registration.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Only perform a single check at initialization time to see if the probe is
equipped with a power-switch. This is done in preparation for revision B
support which has this kind of information encoded in EEPROM.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
After opening the USB device, set the device configuration to 1.
Actually, do it twice, just as the vendor driver seems to do. This
is supposed to trigger a lightweight reset of the device.
Originally, I omitted this reset sequence from the sigrok driver
because it simply did not work at all for me. However, it does seem
to work now, so that may have been a problem in libusb or the kernel
which is now fixed.
With some luck, this change may finally fix#327.
Use states SR_ST_ACTIVE and SR_ST_INACTIVE to indicate that the
device is open or closed, respectively. Do not use any of the
other state values. Improve the robustness of the open and close
methods in face of errors. Introduce a separate flag to indicate
that a running acquisition should be canceled.
Prepare the trigger masks at config_commit() time, so that the
trigger setup can be validated before starting an acquisition.
Accordingly, do actually report validation errors back to the
caller.
It turns out that g_stat() breaks apart when using 64 bit stat on
32-bit systems. Since the actual type of GStatBuf is decided when
glib/gstdio.h is included, it is thus possible for GLib itself to
be compiled with a different type than user code.
Ouch. Unfortunately going back to plain stat() also means that we
lose Unicode filename support on Windows.
The GNU libstdc++ headers use isascii(), which is not part of any
POSIX standard. On BSD, this breaks the build. It is however part
of XOPEN, which on Linux is apparently enabled implicitly for C++.
This should fix#649.
Since Autoconf places some important feature flags only into the
configuration header, it is necessary to include it globally to
guarantee a consistent build.
Disallow polling for input/error and output-ready events at the
same time, and ensure only a single FD event source is installed.
Also, do not leak if the FD event source is removed by means
other than calling serial_source_remove().
On MinGW, two implementations of printf() are available: either
the Microsoft native one or a standard-conforming replacement from
gnulib. Since we build in C99 mode, headers such as <inttypes.h>
already select the standard-conforming variant. However, MinGW's
GCC does not seem to know about this and assumes MS-style format
syntax by default, which triggers a lot of wrong warnings.
Thus, on MinGW, explicitly decorate sr_log() with the gnu_printf
format flavor attribute. Also use GLib's printf replacements in
the logging implementation to make sure we link to a conforming
printf on any platform, independently of the compiler flags.
This gets rid of the mistaken -Wformat warnings for sr_log(), but
does not cover functions such as g_strdup_printf() which do not
explicitly specify the gnu_printf flavor in the format attribute.
This can be overcome by adding "-D__printf__=__gnu_printf__" to
CPPFLAGS, but it would be inappropriate for libsigrok to define
this on its own.
The confusingly named sr_log_logdomain_set() simply set a global
string prefixed to the log message by the default log callback.
This is pretty much useless, misleadingly named, and not used by
either sigrok-cli or PulseView.
A few of these were pretty serious, like missing arguments,
passing integers where a string was expected, and so on.
In some places, change the types used by the code rather than
just the format strings.
SR_LOG_DBG and above are targeted at developers, so it makes sense
to extend timestamp output to that. Also sanitize the calculation
of the timestamp components a bit.
Get rid of the specicialized sr_err(), sr_warn(), etc. functions.
Instead, define the logging helper macros in terms of sr_log(),
and remove the sr_log() helper macro so that no function is hidden
by a macro anymore.
Decorate sr_log() with G_GNUC_PRINTF to detect varargs errors. This
unearthed a gazillion warnings all over the place which will have
to be fixed.
Also convert the helper macros to ISO C99 __VA_ARGS__ style instead
of relying on a GNU C extension. Paste the log prefix directly into
the format string to make this work.
Some drivers, such as zeroplus-logic-cube, run everything they do
right away in dev_acquisition_start(), never installing any event
sources. Handle that evilness by returning from sr_session_run()
immediately if there are no sources.
Replace the custom session main loop with the GLib main loop.
This is phase one of the port, which leaves the session and
driver APIs unchanged while replacing the internals.
The Hung-Chang DSO-2100 is a parallel port PC oscilloscope sold back
in 1999 under brand names like Protek and Voltcraft.
This inital version of the driver has the following limitations:
- Hardcoded calibration values. All parameters are set to 50%.
- No support for auto triggering
- No support for TV sync trigger modes
- No support for the "scroll acquisition" mode
In scroll acquisition mode the device behaves more like a multimeter
and reports the current voltage of a probe on request. While in this
mode the sample rate is limited by the parallel port interface, it is
the only way to capture both channels at the same time (well, sort of).
Calibration would need auto triggering. The calibration values are very
temperature dependent and the device takes literally hours to reach its
final temperature. Every vdiv setting needs its own set of calibration
values. Without hardware modifications, the calibration settings wear
of in less than a second while waiting for a trigger because the
capacitors storing those values are not recharged in state 0x21.
This is set to | (or left empty) by SR_PROG_MAKE_ORDER_ONLY for
portability reasons, since not all Make implementations support
order-only prerequisites.
This is intended to make people notice when libusb is too old
for the new Windows code. However, this is not foolproof, since
the libusb version may be different at runtime.
Introduce new internal session API for changing the set of polled
file descriptors for an already installed event source. Use the
new API to apply changes to the USB poll FDs when requested to do
so by libusb. Doing so is necessary to make the generic USB code
work on Windows.
Provide SR_ARG_OPT_CHECK, a generalized variant of SRG_ARG_OPT_PKG
that can be used with custom check commands. Implement the latter
in terms of SR_ARG_OPT_CHECK.
There was a problem in scpi_serial.c in the scpi_serial_read_data()
function. Incoming data was written at the read position in the buffer,
although it should be written at the count position in the buffer.
This is another attempt at getting the mess that is libusb event
handling on Windows under control. Until libusb makes its HANDLEs
available for polling, we have no choice but to block while waiting
for libusb events. Since we do not want to force drivers to deal
with multi-threading issues, that means we have to block in the
session main loop.
Fortunately, it turns out that our drivers aren't using multiple
event sources, so it is actually possible to block the main loop
without disrupting too much. This also gets rid of the USB thread
on Windows. Thankfully, libusb does not seem to care that we are
now calling libusb_handle_events_timeout_completed() twice per
iteration: first a blocking call (with timeout) in the callback
wrapper, followed by the non-blocking call in the driver-supplied
callback.
Turns out that having one event source per libusb poll FD is
a bad idea. There is only a single callback for all poll FDs,
and libusb expects to be called only once per poll iteration,
no matter how many FDs triggered.
Also, they should all share the same timeout, which should get
reset on events from any polled FD. The new timeout handling made
this problem apparent, as it caused the callback to be invoked
multiple times on timeouts, once for each separate event source.
In order to fix this, change the implementation to allow for an
arbitrary number of poll FDs per event source. This number is
zero for timer FDs, one for normal I/O sources, and one or more
for libusb sources (Unix only).
Also, on Windows, do not get an additional timeout from libusb
in the event loop. This is only appropriate when polling the
libusb FDs directly, which we aren't doing on Windows.
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.
Looking at the g_poll() implementations for various systems, it
appears that on Windows the return value is 0 if the wait was
interrupted, and errno is never set. Also, the MacOS X wrapper
around select() does not clear revents on timeout.
To deal with these issues, check for EINTR only on Unices, and
assume revents to be invalid unless g_poll() returned a positive
value.
If the call to g_poll() in sr_session_iteration() fails, report
the error back to the caller. Do not treat EINTR as error though.
Check for session abort only if a source callback was actually
invoked, or at least once if none of the callbacks are invoked.
Stop checking for abort if the session has already been stopped,
just in case a callback sets abort_session again.
Also change the documentation to match the actual behavior.
In sr_session_iteration(), remove the inverted evaluation of the
block parameter if a USB source is present. This stops the deluge
of USB event callbacks due to the timeout always being zero.
Also, just for cleanliness, initialize the revents member of each
GPollFD instance to zero.
SWIG_init() returns void for Python 2.x and 'PyObject *' for Python 3.
Use an #if to handle both cases properly, otherwise the Python bindings
for either Python 2 or 3 will fail to build.
Python 3.x failure:
sigrok/core/classes_wrap.cpp: In function ‘PyObject* PyInit__classes()’:
sigrok/core/classes_wrap.cpp:59002:5: error: return-statement with no
value, in function returning ‘PyObject* {aka _object*}’ [-fpermissive]
return;
^
Python 2.x failure:
In file included from /usr/include/dirent.h:244:0,
from /usr/include/glib-2.0/glib/gdir.h:32,
from /usr/include/glib-2.0/glib.h:45,
from /usr/include/pygobject-3.0/pygobject.h:7,
from sigrok/core/classes_wrap.cpp:3179:
sigrok/core/classes_wrap.cpp: In function ‘void init_classes()’:
sigrok/core/classes_wrap.cpp:59002:12: error: return-statement with a
value, in function returning 'void' [-fpermissive]
return NULL;
^
This was superfluous -- there is no need to be able to query the
last MQ(s) sent by the device, since they're already being sent
along with the measurements in analog packets.
Since there is also no way to change the MQ (that is done with the
buttons on the device), there is no need to even list the possible
MQs.
The need to make this a list no longer applies.
SR_T_MQ is thus a type consisting of a tuple with two elements: the first
item is the MQ (type G_VARIANT_TYPE_UINT32), and the second is the MQ
flags value (G_VARIANT_TYPE_UINT64).
After the packet has been passed through the transformation modules,
the transformed data is in packet_in but the following code uses
the packet variable which still points to the original input.
This fixes bug #631.
Make vxi.h the first #include in all affected files and #undef the
_POSIX_C_SOURCE macro in vxi.h.
This avoids various build issues on e.g. FreeBSD or Mac OS X where
setting _POSIX_C_SOURCE leads to the unavailability of certain types
such as u_long (as used in the VXI/RPC code).
Extend setup.py to allow environment variables to be set on the
command line. Use that functionality to replace the pkg-config
invocations with flags passed on from make. Suppress the annoying
-Wstrict-prototypes warning by overriding the OPT variable.
Also move the "cd bindings/python" from Makefile.am to setup.py
to side-step problems with "cd" in make rules.
This also fixes bug #628.
- SR_MQ_MASS: Mass, as measured by scales / balances.
- SR_UNIT_*: Various units of mass.
- SR_MQFLAG_UNSTABLE: A flag denoting that a value has not
yet stabilized (settled). E.g. when placing an object on a scale
it'll take a few moments until a stable reading is available.
Measurement values marked with SR_MQFLAG_UNSTABLE denote that they
are "unsettled", unstable values (not yet stabilized).
The absence of SR_MQFLAG_UNSTABLE denotes that the value is stable.
- SR_CONF_SCALE: A device class for weighing scales / balances.
This basically makes glibc expose the same set of features as
if gcc was invoked without any restricting -std=c* option. Unlike
_GNU_SOURCE however, it does not enable GNU-specific extensions.
So, with this macro defined the behavior of Linux with glibc
should match that of other platforms.
In order to avoid confusion of the flags-gathering pkg-config
result with the actual test for the availability of "check",
change the pkg-config output variable prefix from CHECK to TESTS.
This type consists of an array, with each item a two-member tuple,
representing an MQ/MQflags pair: the first item is the MQ (type
G_VARIANT_TYPE_UINT32), and the second is the MQ flags value
(G_VARIANT_TYPE_UINT64).
A GVariant of type SR_T_MQLIST can thus always represent more than
one MQ/MQflag pair.
The tables defined with this struct can now be used for information
on items other than config keys.
Functions to access these tables have been renamed sr_key_info_[name_]get.
These take an extra argument, keytype, which should be set to SR_KEY_CONFIG
to get the config key tables. Other key types will be added.
Put the extra libraries into SR_EXTRA_LIBS instead of LIBS.
Create an SR_CHECK_LIBS macro to make that easy. Substitute
SR_EXTRA_LIBS into libsigrok.pc, too.
Place a copy of ax_cxx_compile_stdcxx_11.m4 from the Autoconf
macro archive into our private m4/ directory. This is cleaner
than trying to parse M4 file versions etc. Plus, the macro is
now always available.
Use autoreconf instead of invoking the various Auto tools
separately. Get rid of the Darwin-specific guesswork -- it
does not make sense to handle this at the level of libsigrok.
People should set up their ACLOCAL_PATH themselves as appropriate
for their own system; just as they already need to set up various
other paths.
Introduce the SR_CHECK_COMPILE_FLAGS macro and use it to check
for additional compiler flags. Put the accepted flags into the
separate substitution variable SR_EXTRA_CFLAGS.
With this and the preceding changes, bug #578 should now be fixed.
Use the SR_ARG_ENABLE_WARNINGS macro to configure and check for
the availability of compiler warning flags. Maintain separate
sets of warning flags for C and C++.
The configure option --enable-warnings=[min|max|fatal|no] can
be used to set the compiler warning level for all languages.
The default level is "max".
Place custom Autoconf macros which other sigrok modules may
re-use into a separate file m4/sigrok.m4. Also, introduce new
macros for defining the package and library versions, and for
gathering compiler warning flags.
It seems that contrary to what the documentation says, leaving
the category argument to m4_warn() empty is not allowed. Use
the "unsupported" category for lack of a better choice.
Although useful, makes other than GNU make do not like this.
Name the prerequisite explicitly instead, and circumvent any
VPATH substitution other makes may do.
It can sometimes happen that .git/HEAD or .git/refs/head/*, which
are added as config.status dependencies during configure, do not
exist anymore at build time. For instance, when the current branch
is deleted after switching to a different one.
Wrap the dependencies inside $(wildcard ...) to avoid this problem.
Note that this is a GNU make feature. However, it should be fine
as it is only used for git builds. Even if a non-GNU make is used,
the construct will hopefully just expand to nothing.
Replace DRIVER() and DRIVER2() by a single SR_DRIVER() macro.
Derive the names of shell variables and preprocessor defines
programatically to cut down on repetition.
version.h and enums.hpp are generated at build time and should
not be included in the distribution tarball. This seems to have
triggered a weird error when doing a VPATH build of the dist
tarball.
It seems automake automatically adds the directory containing
the generated version.h to the include path. Use nostdinc to
disable default includes altogether.
This fixes a build problem due to the reduced include search paths
introduced by my recent changes. Also fix a couple of other
includes to use angle brackets.
Append the git revision hash to the libsigrok package version,
unless HEAD exactly matches a release tag. Note that this does
not affect the version known to autoconf -- e.g. source tarballs
created by make dist will not receive a revision suffix.
Changes to git HEAD automatically trigger a reconfiguration.
Uncommitted changes do not, which is why I left out the -dirty
suffix.
Make it so that $(datadir) is resolved at make time, as per
autotools recommendations. Note that $datadir is not fully
resolved at configure time to begin with, i.e. part of it
already was evaluated at make time.
Use the proper tool for the job and make libsigrok/version.h
a secondary configuration header, so that autoconf's AC_DEFINE
machinery can be used to generate it. Note that the header
template is still hand-written, enabling fine control of the
content.
Move the include flags for files in the source tree from
configure.ac to Makefile.am where they belong. Also use
AM_CPPFLAGS instead of CFLAGS/CXXFLAGS to make sure the
files in the build/source tree are always picked up first.
Also, remove the include/libsigrok sub-directory from the
search path, thereby making the <libsigrok/> prefix mandatory
when building libsigrok itself. This matches the convention
already imposed on users of the library.
- Don't #include <errno.h> in files that don't actually need it.
- Don't use strerror() on error codes from functions that don't set
errno. Replace strerror() with sr_strerror() for libsigrok functions.
Fixes a bug where new acquisition failes due to leftover pipes from
previous acquisitions:
sr: demo: dev_acquisition_start: pipe() failed
Indeed, PulseView had 2024 pipes opened. With this fix, it stabilizes at
33 with sampling thread active.
Signed-off-by: Hubert CHAUMETTE <hchaumette@baylibre.com>
Move the libusb_detach_kernel_driver() call after the code that
sets the usb->devhdl pointer, otherwise it'll be NULL and result
in a segfault.
#0 libusb_kernel_driver_active (dev=0x0, interface_number=0) at libusb/core.c:1711
#1 dev_open (sdi=0x12d99f0) at src/hardware/fx2lafw/api.c:374
[...]
Tested on a device with the default Cypress VID/PID and one with
the Saleae Logic VID/PID, both works fine.
The timerfd descriptor is closed automatically by
g_io_channel_shutdown(). No need to close it manually.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
At high sampling rates and maximum channels we are not able to acquire
samples fast enough, even though frontends still think that samples
arrive on time. This causes visible shifts in frontend plots.
To compensate for the delay introduce the following workaround: check
if we are late (if any clock events have been missed) and resend the
last frame n times (n == number of missed clock events).
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Currently baylibre-acme uses a fake pipe as the input channel required by
libsigrok API and calls sleep() in the data acquisition callback to create
intervals between measurements.
Switch to a more elegant approach: use Linux' timerfd and set a periodic
timer equal to the sampling rate. Then read the data every time the timer
expires.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Opening a file has a cost (security, allocation, syscalls). The
read_sample() function always does an open/read/close sequence.
In order to optimize that, let's open the file at the moment the
acquisition starts, close it when the acquisition stops and make
read_sample() only lseek() to the beginning of the file and read
the value.
Signed-off-by: Daniel Lezcano <daniel.lezcano@free.fr>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
This was originally done as an optimization in combination with a list
reversal which has since been removed from the code. Thus, un-reverse
the channels so that the UI lists them in the correct order again.
When the import of gi.repository.GLib failed, we would get a NULL
pointer that we passed along without any checking. In this situation,
the entire program would crash with a segmentation fault, and no
message to indicate the problem.
When the import fails, abort the SWIG init and print a message. The
Python interpreter then prints out a backtrace, which can be useful
in tracking down the problem.
The Chroma 62000P series comes in various models with different
current and voltage capabilities. These are encoded in the *IDN
string, so just get them from there, rather than needing a profile
for every model.
All those options are currently applied only to power-supplies
but they could apply as well to electronic loads, except for the
fact that electronic loads channels are called inputs and not
outputs.
Also when you think about an SMU (or any kind of 4-quadrants
power-supply), their channels can both source and sink current,
so they can be considered as input as much as output.
Those SR_CONF_* are thus renamed so that they can be used in all
those situations.
For devices such as the HP 6632B the following invocation was failing due to
scpi_cmd(sdi, SCPI_CMD_SELECT_CHANNEL, ...) returning SR_OK_CONTINUE.
./sigrok-cli -d scpi-pps:conn=/dev/ttyUSB0:serialcomm=9600/8n1 --continuous
sr: session: sr_session_start: could not start an acquisition (not enough data to decide error status yet)
Failed to start session.
This patch only adds the needed infrastructure to control output
frequency in the same manner as output voltage or current limit. This
does require a new field in the channel_spec struct, for the sake of
symmetry.
This makes 'output_frequency' symmetrical with 'output_current' and
'output_voltage'. On a more fundamental level, there's no reason why
frequency should be treated as a discrete quantity, other than
"es51919 used it this way".
Only the capabilities which map directly to SCPI commands supported by
sigrok are implemented at this time. This is sufficient to control
the most often used functionality of this AC source
Some devices with more than one microcontroller report the firmware
version for each of them, giving us more than four tokens. When that
happens, sigrok aborts, even though it received a valid response.
This happens, for example with the Chroma 61604:
'Chroma ATE,61604,001060,1.25,1.34,1.20'
With gcc 5.1 released and defaulting to std=gnu11, the code will be compiled
according to different standards depending on the compiler version so we
should better specify explicitly what standard we are targetting.
C11 is now quite mature, it is supported in the just release Debian stable
(gcc 4.9) and also in old-stable (gcc 4.7), so there should be no reason to
use anything more ancient.
We also should have no reason to need any non-standard GNU extension.
So using only C11 + POSIX sounds like the best option right now.
isascii() is a superset of isalpha() and isblank() so the current
code doesn't really make sense.
Moreover, isascii(x) is just a funky and non standard way to
write x < 128.
../src/backend.c: In function 'sr_init':
../src/backend.c:435:1: warning: label 'done' defined but not used [-Wunused-label]
done:
^
../src/device.c: In function 'sr_dev_inst_connid_get':
../src/device.c:525:7: warning: unused variable 'connection_id' [-Wunused-variable]
char connection_id[64];
^
../src/device.c:524:20: warning: unused variable 'b' [-Wunused-variable]
int r, cnt, i, a, b;
^
../src/device.c:524:17: warning: unused variable 'a' [-Wunused-variable]
int r, cnt, i, a, b;
^
../src/device.c:524:14: warning: unused variable 'i' [-Wunused-variable]
int r, cnt, i, a, b;
^
../src/device.c:524:9: warning: unused variable 'cnt' [-Wunused-variable]
int r, cnt, i, a, b;
^
../src/device.c:524:6: warning: unused variable 'r' [-Wunused-variable]
int r, cnt, i, a, b;
^
../src/device.c:523:22: warning: unused variable 'drvc' [-Wunused-variable]
struct drv_context *drvc;
^
Check the return value of sr_gpio_setval_export() in bl_acme_set_power_off()
and return an appropriate error if the call fails.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
This reverts commit 4cd97e5ad7.
We should actually check the return value of sr_gpio_setval_export().
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Add LIBUSB_CALL where needed to avoid warnings such as the following:
In file included from src/hardware/hantek-dso/api.c:34:0:
src/hardware/hantek-dso/dso.h:212:13:
note: expected 'libusb_transfer_cb_fn' but argument is of type 'void (*)(struct libusb_transfer *)'
SR_PRIV int dso_get_channeldata(const struct sr_dev_inst *sdi,
^
src/input/wav.c:41:0: warning: "WAVE_FORMAT_PCM" redefined
#define WAVE_FORMAT_PCM 0x0001
^
In file included from [...]/include/windows.h:86:0,
from [...]/include/libusb-1.0/libusb.h:70,
from ./src/libsigrok-internal.h:31,
from src/input/wav.c:28:
[...]/include/mmsystem.h:482:0: note: this is the location of the previous definition
#define WAVE_FORMAT_PCM 1
^
CC src/hardware/baylibre-acme/protocol.lo
../src/hardware/baylibre-acme/protocol.c: In function 'bl_acme_set_power_off':
../src/hardware/baylibre-acme/protocol.c:417:6: warning: variable 'val' set but not used [-Wunused-but-set-variable]
int val;
^
Both ina2xx and tmp401 linux drivers used by baylibre-acme expose
the standard hwmon update_interval attribute, which affects the internal
update interval of the chip.
When setting samplerate for data acquisition try to modify this
attribute accordingly.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
PROBE_FACTOR and POWER_OFF options are advertised for all ACME probes
(channel groups) regardless of whether they actually have given capability.
Check these options in config_list() at runtime and only advertise them
for probes which support them.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
For Windows builds (which require MinGW-w64) we currently support:
- cross-builds using MXE (mxe.cc) and possibly other cross-compile setups
- native builds using MSYS2 (sf.net/projects/msys2/)
Neither of those require explicitly specifying ACLOCAL_DIR.
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.
We should have been doing this all along, but we get away with it
on Linux where libusb can do everything with fds, and we get away
with it for many drivers that have a short timeout on their events.
On Windows though, handling this correctly is essential.
Fixes bug #343.
This temporarily reverts commit 421bc3eba0.
We cannot yet use the sr_config_*() wrappers, otherwise loading *.sr
files is broken. A fix is being worked on.
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.
Tested on an MSO1104Z with firmware 00.04.02.SP4.
The analog channels are captured correctly. For the MSO series, with digital
channels, there are two outstanding issues:
1. Logic data is retrieved per-channel, one byte per sample, with the value
in the LSB of each byte. The current datafeed logic format doesn't allow
this format to be passed on directly. I suggest we resolve that rather than
making the driver buffer and interleave the data.
As stands, the code will retrieve data for all channels and pass it onto
the datafeed with unitsize=1. Channel D0 can used correctly if selected
alone. For other channels, data is passed to the frontend but the API does
not provide a way to associate it with the correct channel.
2. Channels CH3 and CH4 are multiplexed with D0-7 and D8-15 respectively, so
enabling these is mutually exclusive. We don't currently have a way to
express this constraint to the frontend.
This patchset was originally done by eightdot <gituser@eightdot.eu> by
manually forward-porting parts of the changes done by Bert Vermeulen (see
previous commits), but then heavily modified by Uwe Hermann to be based on
top off the (git-)rebased patches from Bert Vermeulen instead.
Note: This initial DSLogic code is *not* yet in a working or usable
state. It should be considered as a basis for further work only, for now.
CC src/hardware/openbench-logic-sniffer/api.lo
../src/hardware/openbench-logic-sniffer/api.c: In function 'scan':
../src/hardware/openbench-logic-sniffer/api.c:103:10: warning: unused
variable 'probefd' [-Wunused-variable]
GPollFD probefd;
^
Use the more portable sp_input_waiting() instead of g_poll() with FDs.
Thanks to Martin Ling for the hints. This is tested on Linux and Win7
using an OLS; scanning for the device and starting an acquisition works.
Also, add some more debug output.
This fixes bug #562.
Split device options into general and channel group settings, and
adjust config_list() callback appropriately.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Current exclude patterns lead to unwanted exclusion of all paths
containing common directory names like output, bindings etc. even
if those names occur higher in the directory structure.
Make exclude patterns more specific by prefixing them with src/.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
There's indeed no g_fclose() unfortunately. The g_*() wrappers for file
handling are mainly there to deal with portability issues in file names
(encoding, character sets, etc) on different platforms.
Use PRIu64 to avoid the following compiler warning:
CC src/hardware/baylibre-acme/gpio.lo
protocol.c: In function 'bl_acme_set_shunt':
protocol.c:341:2: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 3 has type 'uint64_t' [-Wformat=]
g_fprintf(fd, "%llu\n", MOHM_TO_UOHM(shunt));
^
Implement support for SR_CONF_PROBE_FACTOR setting in BayLibre ACME
driver. Given the channel-group parameter this allows to set the
shunt resistance for each probe.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Add new configuration option allowing to modify the probe factor
for oscilloscopes and power-monitors.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
The driver for BayLibre ACME depends on Linux-specific sysfs
interfaces to ina226 and tmp435 devices. Exclude it for different
targets.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Implement basic functionalities for baylibre-acme. Add support
for common config options, device detection and sample reading.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
We try to find the smallest diff by comparing each diff with
the previously known smallest diff, so initially, this smallest diff
should be INFINITY so that we are sure to find a smaller one.
This fixes the following exception:
sr: rigol-ds: Negative vdiv index: -1.
Caught exception: not applicable
These are available on e.g. Rigol DS1102E (or "upgraded" DS1052E).
Without this, if one of the channels happens to have been set to
one of the missing vdiv settings frontends (e.g. PulseView) will
have some trouble using the scope:
sr: hwdriver: sr_config_get(): key 30012 (vdiv) sdi 0x11bcb70 cg CH1
sr: rigol-ds: Negative vdiv index: -1.
std::exception
Mixing tests for both a boolean and an SR_ERR at the same time is not
really a good idea.
parse_header() actually returns a boolean so only check if it returns FALSE.
This fixes the following gcc-5 warning:
src/input/vcd.c: In function 'receive':
src/input/vcd.c:506:34: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
if (!parse_header(in, in->buf) != SR_OK)
^
Inlining can only happen in the same compilation unit where the
function was defined, so there is no sense declaring an inline
function in a header if this function is not defined in this
same header.
This fixes the following gcc-5 warning:
In file included from include/libsigrok/libsigrok.h:1066:0,
from src/version.c:21:
include/libsigrok/proto.h:36:20: warning: inline function 'sr_rational_set' declared but never defined
SR_API inline void sr_rational_set(struct sr_rational *r, uint64_t p, uint64_t q);
^
Commit 5801d558 replaced g_slist_copy_deep() by some incorrect code
that actually leaks the newly allocated memory, instead of doing
a deep copy.
This new version should be more correct, more concise, and it fixes
the following warning:
src/session.c: In function 'sr_packet_copy':
src/session.c:1025:38: warning: passing argument 2 of 'g_slist_foreach' from incompatible pointer type [-Wincompatible-pointer-types]
g_slist_foreach(meta_copy->config, (GCopyFunc)copy_src, NULL);
^
In file included from /usr/include/glib-2.0/glib/gmain.h:26:0,
from /usr/include/glib-2.0/glib/giochannel.h:33,
from /usr/include/glib-2.0/glib.h:54,
from src/session.c:24:
/usr/include/glib-2.0/glib/gslist.h:125:10: note: expected 'GFunc {aka void (*)(void *, void *)}' but argument is of type 'void * (*)(const void *, void *)'
void g_slist_foreach (GSList *list,
^
Add new error code which can be used to notify the user about
general input/output errors.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
In order to determine the target OS when cross-compiling libsigrok
we need autotools to set the 'target_os' variable. This macro
determines the system type and sets output variables to the names
of the canonical system types.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
(lwla_convert_trigger): Fix trigger mask computation bug introduced
by recent change: Widen constant to 64 bit before shifting so that
channel nunmbers beyond 32 are processed correctly.
By avoiding g_slist_copy_deep() for now, we can easily allow libsigrok
to build against glib 2.32 (less hassle for users of stable/older
distros or OSes).
Gnuplot doesn't have any "official" file name extension(s). It uses
(at least) two different types of files basically:
- "control files": These can have many different somewhat commonly
used extensions such as .gpi, .gnu, .gnuplot, .gp, .plt, .gih,
others. These files don't contain data, only Gnuplot commands such
as 'set yrange [75:105]', 'set ylabel "foo" offset 1', and so on.
- "data files": This is what libsigrok reads and writes. These files
contain actual data to be graphed by Gnuplot (with the help of a
specially-crafted control file, see above). The data is usually in
a tab-separated format. The common file extension is usually .dat,
though many others are possible as well.
- 'struct sr_input *' variables are consistently named 'in'.
- 'struct sr_input_module *' variables are consistently named 'imod'.
- 'struct sr_output *' variables are consistently named 'o'.
- 'struct sr_output_module *' variables are consistently named 'omod'.
Fix "undefined reference to `sigrok::EnumValue<sigrok::LogLevel,
sr_loglevel>::_values'", which happens at least when using clang(++),
e.g. on Linux, Mac OS X, or FreeBSD.
This fixes bug #534.
Thanks to Uffe Jakobsen and Martin Ling for reporting and investigating!
Currently (as of date 20150122) an ioctl problem within the
FreeBSD kernel is preventing libusb_get_port_numbers() from working.
Hence calls to libusb_get_port_numbers() will always return 0.
This makes it impossible to establish a physical path the the usb device.
This problem has existed "forever" -
meaning that libusb_get_port_numbers() has never worked.
A fix is committed to FreeBSD "current" head -
and will later be merged (MFC'ed) to maintenance branches.
See: https://svnweb.freebsd.org/base?view=revision&revision=277417
Additionally FreeBSD requires that devices prior to calling
libusb_get_port_numbers() have been opened with libusb_open().
The patch is "forwards-compatible".
Currently it acts specificly to libusb_get_port_numbers()
currently returning 0 on FreeBSD.
In these situations it constructs an artificial path to the device.
When FreeBSD kernels appears with proper working ioctl
supporting libusb_get_port_numbers() the code will construct
proper physical paths for newer kernels - while still generating
artificial physical paths for older defective kernels.
Add new config options to libsigrok - 'averaging', which allows to
enable averaging of samples and 'avg_samples' for setting the number
of samples to be averaged over in each cycle.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
This fixes a Doxygen warning:
src/input/input.c:209: warning: The following parameters of sr_input_new(const struct sr_input_module *imod, GHashTable *options) are not documented:
parameter 'imod'
As per upstream docs "#include <glibmm.h>" is the correct usage,
the "glibmm-2.4" directory is handled correctly via pkg-config:
$ pkg-config --cflags glibmm-2.4
-I/usr/include/glibmm-2.4 [...]
libsigrokcxx.pc has a "Requires" field listing "libsigrok" which
will cause libsigrok's "Requires.private" entries to be used/inherited
when 'pkg-config --libs --static libsigrokcxx' is used.
On a Hameg HMO1024 you get incomplete data because the USB transfer takes
longer than the scpi->read_timeout_ms of 1 second that is defined in
scpi_dev_inst_new(). Therefore reset the timeout in sr_scpi_get_string()
whenever the device sends a partial response.
Since every individual measurement is represented by a single frame
and a "sample" isn't all that meaningful concept in this context,
it makes more sense to define possible limit in number of frames.
Make the es51919 driver to support setting a frame limit instead of
a sample limit.
In most, but not all, modes the ES51919 reports two separate
analog values for each measurement sample. These values are
mapped to two separate channels and sent in two separate
packets.
A client program needs a way to determine which results are
parts of the same measurement and also know when a complete
measurement is received so it can process the sample. Use
the frame begin and end packets to separate groups that each
represent a single complete measurement.
This removes an unnecessary build dependency on JDK and fixes
build troubles on systems where javac is present but JDK is not
installed and Java bindings are disabled by ./configure --disable-java.
When libusb cannot access a device, libusb_get_port_numbers() will return
an error. Check the return code rather than doing invalid pointer
operations (out-of-bound read).
Avoid segfaults at sigrok-cli startup on my setup where some USB devices are
not accessible and also make Valgrind happier.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Silence some warnings when building the Python bindings:
sigrok/core/classes_wrap.cpp: In function ‘PyObject* _wrap_new_OutputFormatMap(PyObject*, PyObject*)’:
sigrok/core/classes_wrap.cpp:5232:4: warning: ‘argv[0]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
res = SWIG_ConvertPtr(obj,(void**)&p,swig::type_info<map_type>(),0);
^
sigrok/core/classes_wrap.cpp:14383:13: note: ‘argv[0]’ was declared here
PyObject *argv[2];
^
sigrok/core/classes_wrap.cpp: In function ‘PyObject* _wrap_new_ChannelGroupMap(PyObject*, PyObject*)’:
sigrok/core/classes_wrap.cpp:5232:4: warning: ‘argv[0]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
res = SWIG_ConvertPtr(obj,(void**)&p,swig::type_info<map_type>(),0);
^
sigrok/core/classes_wrap.cpp:23356:13: note: ‘argv[0]’ was declared here
PyObject *argv[2];
^
We add -Wno-uninitialized since the warnings are harmless and we really
don't care about them in the generated classes_wrap.cpp.
This fixes parts of #417.
All of these error conditions are checked via the unit tests.
Also, add the following missing entries (analog trigger types):
- SR_TRIGGER_RISING
- SR_TRIGGER_EDGE
Use g_malloc0() for small allocations and assume they always
succeed. Simplify error handling in a few places accordingly.
Don't always sanity-check parameters for non-public (SR_PRIV)
functions, we require the developers to invoke them correctly.
This allows further error handling simplifications.
This is a feature restricted to the new analog struct.
By default all the digits available in the encoding struct are printed.
The option "digits", when set to "spec", changes this to print the
number given in the spec struct.
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.
This fixes an error message when the file is not installed at all:
./autogen.sh: 67: [: Illegal number:
Turn the AX_CXX_COMPILE_STDCXX_11 errors into warnings though, since
it is (and should be) possible to build libsigrok (just the C library)
just fine, even without that macro or with an older version of it.
Those need a bugfix to make them build again:
bindings/java/org/sigrok/core/classes/Context.java:92: error: method Context_create_analog_packet in class classesJNI cannot be applied to given types;
long cPtr = classesJNI.Context_create_analog_packet(swigCPtr, this, ChannelVector.getCPtr(tempchannels), SWIGTYPE_p_float.getCPtr(data_pointer), num_samples, Quantity.getCPtr(mq), mq, Unit.getCPtr(unit), unit, QuantityFlagVector.getCPtr(mqflags), mqflags);
^
required: long,Context,Vector<Channel>,long,long,long,Quantity,long,Unit,long,QuantityFlagVector
found: long,Context,long,long,long,long,Quantity,long,Unit,long,QuantityFlagVector
reason: actual argument long cannot be converted to Vector<Channel> by method invocation conversion
1 error
Makefile:3352: recipe for target 'bindings/java/sigrok-core.jar' failed
The automatic selections of the measured quantity and equivalent circuit
model are more part of the configuration of the meter than attributes
of the measurement result. To reflect this, model them as config keys
instead of mqflags. This allows a driver that supports remote control to
implement 'set' method for them and has the additional benefit of saveing
two flag bits.
If the number and specs of the device's channels are not static, i.e.
need to be probed, this facility is needed.
Initially this will be used for the Philips PM2800 series, where only
the model returned by *IDN? is needed. However this could also be used
to do actual discovery with vendor-specific SCPI commands.
Since the DER EE DE-5000 driver is currently the only user of
the es51919 module and it depends on the libserialport, compile
the module only if the DER EE DE-5000 driver is enabled. This
allows libsigrok to be built without libserialport again.
At least the Rigol DP800 series trigger the beeper when changing
channels remotely. Which gets rather annoying when doing acquisition
on three channels as fast as you can.
Add a driver for the DER EE DE-5000 LCR meter. This meter is based on
the Cyrustek ES51919/ES51920 chipset and communicates with the host
computer via an optional connectivity kit.
The kit uses an optoisolated unidirectional link to connect to the
meter and an USB cable on the host side. Internally the connection is
using the FTDI FT232R USB UART chip i.e. from the host computer point
of view the meter is connected into an RS-232 serial port.
This driver implements just a thin shim layer for registering the
driver and uses the es51919 module for all the actual work.
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.
Add flags for indicating that the meter has selected the measured
quantitiy and/or the used measurement model automatically. These
are similar to the existing auto-range flag.
Add 'SR_MQ_DIFFERENCE' quantity for reporting relative difference
between the current measurement and the reference value. The value
of this quantity will normally be reported in percents. Add also
the flag 'SR_MQFLAG_REFERENCE' for indicating that the reported
value is not the current measurement but the reference value instead.
Add parallel and serial model inductance, capacitance and resistance
for LCR meter measurements. Add also secondary quantities many LCR
meters calculate, namely dissipation factor, quality factor and phase
angle.
Add degrees and henrys to the list of supported units. Degree is
an unit of plane angle where one degree is 1/360th of a full circle.
Henry is the SI unit of inductance.
Prior to this patch a call to get() with an invalid enumeration value
would raise an exception that would, for example, terminate the python
interpreter, whereas now the exception is handled and translated into a
proper python exception.
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 cleans up some warnings generated by clang's static analyzer.
The function now also returns SR_ERR to signify the specified filename
does not point to a valid session file.
Other SR_ERR_* returns indicate a session file was found, but loading
failed.
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.
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.
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.
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 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.
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.
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.
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 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.
This call was previously nonblocking, but there is no handling of partial
writes. It is called from config_set where it is free to block.
Also fix error handling: serial_write can return any negative error code,
not just -1.
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.
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.
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.
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.
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.
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.
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().
libgpib is the userspace component to linux-gpib's kernel modules that
implement low-level interface drivers.
When libsigrok gets userspace GPIB interface drivers, that backend will
be the "official" scpi_gpib.
From sigrok's point of view, this analyzer has two differences:
* It does not require uploading the firmware.
* It returns garbage in some registers used for sanity checks.
Saleae's software ignores that garbage; sigrok only does if it
specifically detects the mcupro clone.
SR_OK: a match was found.
SR_ERR: no match.
SR_ERR_DATA: a match was found but the module cannot handle the input.
SR_OK_CONTINUE: some module didn't have enough data to be sure.
Since AX_JNI_INCLUDE_DIR does not work for cross compilation, don't
invoke it when cross compiling. Also, add a configure option to
set the jni.h include path manually if needed.
This returned an array of structs with an NULL-ed element at the end.
The drivers still do this, but the wrappers now make and free a NULL-
terminated array around it.
sr_output_options_free() now takes the pointer returned by
sr_output_options_get(), instead of the module owning it.
Previous runs of dev_acquisition_start() keep the enabled_channels list
populated if they fail. This means that once an invalid channel
configuration was detected, it will be detected again even if the channel
configuration was changed. With this change, the list will be cleared
before being populated so that any stale entries are removed.
This silences stuff like this (among others), depending on the
Doxygen version used:
Warning: Tag `XML_SCHEMA' at line 1814 of file `Doxyfile' has become
obsolete. To avoid this warning please remove this line from your
configuration file or upgrade it using "doxygen -u"
The BeagleLogic driver needs sys/mman.h and sys/ioctl.h in order to
build, so disable the driver if those headers aren't available.
This is the case (for example) on MinGW.
Output modules are now guaranteed:
- Every option is always given, with the default value if not supplied
by the user, and is the right GVariantType.
- No invalid options are ever passed.
Audio tools processing WAV failes generally need the samples to be in
the range -1 to +1. The scale option adds postprocessing to any samples
going into a WAV file, by dividing the sample values by the given factor.
The Brymen BM25x series supports the BC-20X that is an opto-isolated
serial cable. The link seems to be unidirectional i.e. when activated
the DMM periodically sends updates to the host while the host cannot
control the DMM in any way.
The protocol is documented in "6000-count-digital-multimeters-r1.pdf"
that is available from the manufacturer. Every 15 byte packet consists
of a bitmap where the bits correspond to segments or symbols on the
LCD display i.e. the DMM essentially sends the contents of its screen
to the host in every update. This driver then decodes the measured
quantity, unit and its value from the bitmap.
This is intended for setting (or getting) the amplitude of a source
which doesn't really have an MQ associated with it, such as the demo
driver's analog channels.
The AX_CXX_COMPILE_STDCXX_11 macro is found in the autoconf-archive
package. If this is not installed, invoking the macro spits out an
error message that makes it look like a syntax error. This wraps it
in a check.
This is needed so that the C++ bindings, the header for which
references "libsigrok/libsigrok.h", can have a valid include
directory passed to build them before the headers are installed.
This adds support for the Testo 435-4, with differential pressure
measurement built in, and probes for wind speed and temperature/humidity
at 293 kelvin.
Support for other probe types will have to be added by people with
access to those probes.
Models other than the 435-4 may well work unchanged, but this is
difficult to predict. Most likely new unit types will need to be added,
and possibly the protocol handling may need to be more flexible and
model-dependent to cope with 5-byte values and other minor changes
in the protocol.
The FDTI library changed version, module name and also soname, so add an option to detect it
when the 0.x version is not found. The 1.x API is compatible enough for libsigrok to build.
We need to include unistd.h for usleep():
hardware/asix-sigma/asix-sigma.c: In function 'sigma_fpga_init_bitbang':
hardware/asix-sigma/asix-sigma.c:450:3: warning: implicit declaration of function 'usleep'
usleep(10000);
And we need to tweak the type of chunks_per_read to match dl_lines_total:
hardware/asix-sigma/asix-sigma.c: In function 'download_capture':
hardware/asix-sigma/asix-sigma.c:1161:39: warning: comparison between signed and unsigned integer expressions
dl_lines_curr = MIN(chunks_per_read, dl_lines_total);
The new triggers consist of a set of structs and an API to manipulate
them. Both logic and analog triggers are supported, in an unlimited
number of stages.
A single struct sr_trigger containing its stages and triggers is then
added to the session.
In case of a driver where the hardware supports triggering, the struct
is then converted and used to arm the hardware trigger. Drivers without
hardware trigger support, such as fx2lafw or multimeter drivers, use it
as the basis for a software-based trigger implementation instead.
This driver is neither working nor has it been in a compiling state for
a long time, so unhook it from the build until it is fixed and works.
The files (api.c and protocol.[ch]) are still in git, but won't end up in
released tarballs and they don't get built (neither git nor tarballs).
This also allows us to drop the otherwise unneeded dependency on libudev.
When the MSO-19 driver comes back, it should be in a form that doesn't
require the inherently Linux-only libudev anyway. See also:
http://sigrok.org/bugzilla/show_bug.cgi?id=65
Init the cur_sample_rate to 200kHz. This is now the default sample
rate for the ASIX Sigma if no other is specified by -c samplerate=N
on the command line. Without this change, the driver would crash on
SIGFPE because a division by zero would happen.
Signed-off-by: Marek Vasut <marex@denx.de>
Due to the recent changes in the sigma driver, the trigger handling got
broken. Fix this by properly calculating and propagating the fact that
the trigger happened.
Signed-off-by: Marek Vasut <marex@denx.de>
Pull out the code for decoding the DRAM clusters into separate function.
This shall improve readability some more.
Signed-off-by: Marek Vasut <marex@denx.de>
These two values can pulled out from devc->state, so there really is
no need to pass them as function argument when we already pass the
devc.
Signed-off-by: Marek Vasut <marex@denx.de>
This function could have never returned correct data. Rework the decoding
logic according to the Sigma documentation. This patch also fixes the
handling of partial DRAM lines and partial DRAM clusters.
While at it, do not allocate megabytes of data on stack, just allocate 2KiB
which is plenty for all the work this function needs to do.
Signed-off-by: Marek Vasut <marex@denx.de>
The support for trailing DRAM lines was broken. This patch starts
rework of support for this, but in order to do that, we need to
rework decode_chunk_ts() a little first.
This patch adjusts the decode_chunk_ts() a little to receive the
total amount of events in DRAM line instead of some nonsense value.
This patch temporarily removes the support for the trailing DRAM
lines until the decode_chunk_ts() is fixed to cope with this, so
yes, this patch introduces breakage!
Signed-off-by: Marek Vasut <marex@denx.de>
Instead of this ad-hoc readout voodoo, use proper function to read
the timestemp. One which will not break even on big-endian machines.
Signed-off-by: Marek Vasut <marex@denx.de>
Use proper structure instead of plain buffer of uint8_t for the contents
of DRAM in download_capture(). This is beneficial as we can interpret the
contents easily.
Signed-off-by: Marek Vasut <marex@denx.de>
Clean up the way decode_chunk_ts() is called a little. Introduce a variable
which will not be -1 only in case a trigger happened on the particular DRAM
line.
Signed-off-by: Marek Vasut <marex@denx.de>
In the current configuration, the download capture used 32KiB buffer
for samples. This was the upper limit this function could download
from the Sigma. Even the sigma_read_dram() was only called once to
read up-to 32 DRAM line from address 0x0 in the DRAM.
This patch reworks the function to call sigma_read_dram() in a loop
in case there is need to download more than 32 DRAM lines of data
from Sigma. The data are then correctly passed for decoding to the
decoding function.
Signed-off-by: Marek Vasut <marex@denx.de>
Avoid allocating 32KiB of data on stack in download_capture(). Instead,
do a glib-variant of calloc(1, ) to allocate the data for the samples
which will be downloaded. This avoids explosions of stack on systems
with tight stack limits.
Furthermore, define structures describing the organisation of Sigma's
DRAM memory and start using those instead of ad-hoc preprocessor macros
defining the sizes of various structures in memory.
Signed-off-by: Marek Vasut <marex@denx.de>
The trigger position, stop position and chunk in which the trigger happened
are no longer needed in the global scope. Make those variables local to the
download_capture() function.
Signed-off-by: Marek Vasut <marex@denx.de>
Move all the register I/O that is necessary to do the download of samples
from Sigma into download_capture() function. This makes the downloading
code contained a bit more again.
Signed-off-by: Marek Vasut <marex@denx.de>
Reorder the sigma_capture_mode() function so that the part which handles
the download of samples from Sigma is clearly separated from the tests if
the download should be started.
Signed-off-by: Marek Vasut <marex@denx.de>
Pull out the code handling the Sigma which is in CAPTURE mode into
a separate function. This is so we can start reworking this entire
code easily soon.
Signed-off-by: Marek Vasut <marex@denx.de>
Check the position of ForceStop and Trigger events only in case we
are in CAPTURE state, it's useless to do this unconditionally when
receive_data() is called.
Signed-off-by: Marek Vasut <marex@denx.de>
Decode the logic mode start sequence into a series of FPGA instructions
instead and get rid of this sequence of magic numbers.
Signed-off-by: Marek Vasut <marex@denx.de>
Just encode the opcodes as hexadecimal values. This makes for better
readability when mapping the communication dump with the sigma to the
code.
Signed-off-by: Marek Vasut <marex@denx.de>
Pull out the code which switches Sigma from the FPGA programming mode
into Logic-Analyzer mode into separate function. Also, given the reply
is only ever 3-byte long, do not allocate 32 byte big buffer, but only
a 3-byte long one.
Signed-off-by: Marek Vasut <marex@denx.de>
Move the sigma_fw_2_bitbang() function closer to the upload_firmware()
function so there's not such a horrible mess in the file.
Signed-off-by: Marek Vasut <marex@denx.de>
Rework the bit2bitbang function. Remarkable changes are:
- The function was renamed to sigma_fw_2_bitbang()
- We use glib function calls to work with the file
- We mmap the file containing firmware instead of opening the file
and then reading it into a buffer.
- The magic firmware transformation is now type-safe.
- Documentation and comments were added where applicable.
Signed-off-by: Marek Vasut <marex@denx.de>
Remove all those if ((ret = foo(bar)) < 0) constructs from upload_firmware()
function. This is just a confusing programming practice, kill it. While at it,
replace all the uses of &devc->ftdic with plain ftdic , which is defined at
the begining.
Signed-off-by: Marek Vasut <marex@denx.de>
The code silently assumed the firmware path can be no longer than 128 bytes.
This doesn't scale. This patch fixes it in such a way that it completely
rips out the run-time computation of firmware path and instead replaces it
with compile-time computation. It's true this makes the library grow by a
couple bytes, but makes the code cleaner.
Signed-off-by: Marek Vasut <marex@denx.de>
Rework the pre-firmware-upload FPGA initialization sequence so it matches
the documentation. Also, since this sequence is documented in a separate
section, wrap it into separate function.
Signed-off-by: Marek Vasut <marex@denx.de>
The NUM_CHANNELS macro is inflexible, since in 100MHz and 200MHz modes
we don't support 16 channels. Moreover, it's only used to limit the size
of array of channel labels, which can be done in much cleaner way.
Signed-off-by: Marek Vasut <marex@denx.de>
Add comments to the sampling rate table explaining how the frequencies
are selected and where do those numbers come from.
Signed-off-by: Marek Vasut <marex@denx.de>
(files in hardware/, input/, and output/ don't need this since none of
those directories contain API stuff and are thus not included in the
list of input files for Doxygen at all).
This driver has been unmaintained for years, and was never good code
to begin with. It's also questionable whether it was ever useful,
particularly with the demo driver now supporting various analog
signalling.
This somewhat naively copies whatever it gets into the output, regardless
of how many channels are in there, or which ones are enabled. Not sure
what the best way to deal with that is, but for now you have to feed it
a channel setup the Chronovu software can read.
hardware/fx2lafw/protocol.c: In function 'fx2lafw_command_start_acquisition':
hardware/fx2lafw/protocol.c:113:7: warning: 'cmd.flags' may be used uninitialized in this function [-Wmaybe-uninitialized]
(cmd.flags & CMD_START_FLAGS_CLK_48MHZ) ? "48" : "30");
^
The ChronoVu LA16 is a new logic analyzer from ChronoVu with some
differences in features compared to the LA8, e.g.
- Supports 16 channels (instead of 8).
- Max. 200MHz samplerate (instead of 100MHz).
- Supports state triggering (low and high channel value) and edge triggering
(rising or falling edge), the LA8 only supports state triggering.
This driver now supports both the LA8 and LA16, but it needed a few
changes:
- Add support for detecting multiple device instances at all.
- Add support for both LA8 and/or LA16 devices being detected.
- Add a device profile struct for LA8-/LA16-specific device properties.
- Move the samplerates list to devc (it's different for LA8 and LA16).
- Split scan() into two functions, one for scanning, one for adding a device.
- Expand some variables and fields from uint8_t to uint16_t in order to
support 16 channels.
- Update the samplerate related functions to support the LA16's 200MHz.
- Various other minor updates in order to better handle both device types.
- Various error handling improvements and simplifications.
- Also, replace time() with g_get_monotonic_time() everywhere.
This also fixes bug #247 (which was related to incorrect handling of
resources during scan and open of the device, which was exposed by
PulseView allowing multiple consecutive scan/close/open calls).
Also, consistently use 'ch' for channel variables. This matches how we
consistently use sdi, devc, and so on all over the code-base.
This fixes parts of bug #259.
The name 'probe' (and thus 'probe group') is a relic from the times when
sigrok was mostly about logic analyzers. Nowadays we support a lot more
device types where 'probe' is not really a good term and 'channel' is
much better suited.
This fixes parts of bug #259.
Instead of >= 44 Makefile.am's we now only have one top-level
Makefile.am, and use the 'subdir-objects' automake option to
handle the build via non-recursive (auto)make.
This has the advantage of fewer (boilerplate or other) files and less
clutter in general, as well as performance advantages since the new
setup can build many files in parallel (with 'make -j'), not only 2 or 3
files within the same (e.g. hardware/xxxx/* subdirectory) and also since
we no longer need to build intermediate libtool helper libs per subdirectory.
A quick, non-scientific test build on a quad-core laptop with 'make -j 4'
yields a build time reduction from 35s to 19s.
All autotools features that worked before are still intact without any
regressions, including the Make targets 'install', 'uninstall', 'check',
'dist', 'clean', 'distclean' and so on, as well as all the usual portability
handling (build works on any OS, with any Make implementation such as
GNU Make or BSD Make, with any shell such as sh/ksh/zsh/bash/dash, etc. etc.)
and features such as out-of-tree build support, cross-compile support,
testsuite support (also with colored output), "silent make rules", etc. etc.
Two error checks had a missing "ret = ", which lead to an incorrect
value being passed to libusb_error_name().
Also, lower the level for those messages from sr_err() to sr_dbg()
since they're not fatal.
(parse_contents): Do not call sr_dbg() on every signal change.
This would be excessive even for sr_spew().
(read_until): Do not call ftell() just to be able to show some
number in a debug message later on.
These commands are superfluous and do not seem to make sense in
the context they were used. Also, $dumpvars was missing an $end,
and $dumpoff was used without any content.
Avoid writing a new timestamp for every changed signal if multiple
signals change state simultaneously. Also, keep signal transitions
on the same line with their timestamp to make the output easier to
inspect in a text editor. (VCD does not care whether newlines or
spaces are used to separate tokens.)
(receive): Use probe index for sample byte selection too, not just
for bit selection. Also simplify the indexing expressions a bit.
This fixes the problem of incorrect output for probes indices 8 to
31.
Also, use double rather than float in the timestamp calculation,
and format the result directly as floating point number rather than
converting it back to uint64_t.
Additionally, make sure that the state of all signals is written
for the very first sample in the stream. This fixes the problem
that signals would be displayed as indeterminate until the first
change.
(context.samplecount): Make the sample counter part of the context
struct, rather than keeping it as a global static.
Allow the edge of an external clock input to be configured by
means of an SR_CONF_CLOCK_EDGE configuration setting. This is
a string option with the same format as SR_CONF_TRIGGER_SLOPE.
Implement the configuration setting TRIGGER_SOURCE with the
choices CH (logic channels) and TRG (external trigger input).
Also implement the TRIGGER_SLOPE setting for selecting the
edge to trigger on (rising or falling).
It turns out that all LWLA protocol responses consist either
of 32-bit units or of 32-bit units combined into 64-bit units.
Thus it makes sense to double the basic unit size for reading
from 16 bit to 32 bit.
We cannot do the same for command messages though, as those
actually do use 16-bit quantities in some places, and 32-bit
arguments are not always aligned to 32-bit boundaries.
(acquisition_state.xfer_buf_in): Change unit type to uint32_t,
and update related macros and code accordingly.
(LWLA_TO_UINT32): New macro to replace LWLA_READ32, operating
directly on 32-bit values instead of pointers to 16-bit units.
Make use of a compiler-recognized idiom for bitwise rotation
to efficiently swap the 16-bit halves of a 32-bit word.
(LWLA_TO_UINT16): New macro to replace LWLA_READ16.
(LWLA_READ64): Remove unused macro.
(LWLA_WORD_[0123]): Slightly simplify 16-bit word extraction.
The return code SR_ERR_ARG is intended for reporting unsupported
or inapplicable device configuration settings and is not a hard
error. In order to indicate failure of internal sanity checks,
use SR_ERR_BUG instead.
Without the cast non integer frequencies weren't possible (e.g. with a sampling
frequency of 50Hz we would end up with a signal frequency of 2Hz instead of
2.5Hz). The result were signals which had an incorrect number of samples per
period.
BugLink: http://sigrok.org/bugzilla/show_bug.cgi?id=297
Drivers interpreted the uint64 values to the SR_CONF_TRIGGER_SLOPE
configuration setting in different ways. In order to orthogonalize
the API, change the type of the setting to a string with the same
format as uses for logic probes.
Modify the bitstream loading routine to work directly with the
Raw Binary Files (.rbf) generated by Altera tools. Previously,
a custom format was used which was basically an RBF preceded by
a 4-byte header specifying the transfer length.
The *.sr (libsigrok session) file format has changed since the last
libsigrok release. Frontends using older libsigrok versions will not
be able to read *.sr files created by frontends using the new file format.
Thus, bump the version number of the file format to 2.
Current libsigrok will read both version 1 and version 2 files
correctly, and always write version 2 files.
Move pre-acquisition hardware setup to the new config_commit()
callback. At the moment, the only setting applied at commit
time is switching the clock source, which involves uploading
a new bitstream to the FPGA.
Move setup of channels and trigger masks to the new probe
configuration callback. Although the actual hardware setup
still happens just before acquisition, the new approach
already has the advantage that invalid settings are caught
early.
Also, it turns out that the LWLA1034 allows triggering on
channels which are not enabled for data acquisition. This
feature is now supported as well.
Apparently, frontends may call scan() more than once to accumulate
multiple devices, so do not reset the instance list pointer at the
start of each scan. Also, number devices continuously across scans.
This change moves the handling of series differences out to the points in the
code where they actually matter, unifying the overall structure of the code.
It also adds new VS5000/DS1000 series equivalents for commands that were
previously only implemented on the later models.
After this change, trigger waiting and the 'Memory' data source are supported
on the VS5000/DS1000 series.
(sr_session_start): Just before starting acquisition on
a device, call sr_config_commit() to apply pending config
changes to the hardware device.
(sr_session_dev_add): Ditto. Also, return an error code
if starting acquisition failed.
(sr_dev_driver.config_probe_set): New optional callback enabling
drivers to be notified upon changes to probe settings.
(sr_dev_probe_enable, sr_dev_trigger_set): Invoke new driver
callback on changes.
(sr_dev_driver.config_commit): New optional callback allowing
drivers to defer application of configuration settings until
an explicit call to config_commit().
(sr_config_commit): New public wrapper function.
The maximum sample size that can be set on a device is now published
by sr_config_list(SR_CONF_LIMIT_SAMPLES). This returns a tuple of
uint64_t representing minimum and maximum number of samples.
Report settings at acquisition start as informational messages.
Print a message when the the trigger condition has been met.
Demote some other messages from information to debug, and use
the %zu format for printing size_t values.
(process_sample_data): When expanding run-length samples into
session packets, calculate the number of samples to write in
advance while honoring all constraints. This is cleaner than
checking constraints within the expansion loop. Also, the new
logic always fills up packets exactly to whatever limit applies
first, thereby removing the need for truncation after the fact.
Allow the acquisition to be constrained by time in addition to
a sample count limit. Since the LWLA protocol actually provides
only a duration natively, implement the sample count limit on top
of the new duration limit.
With this change, limiting an acquisition in external clock mode
should finally work properly.
This adds sine wave generation capabilities for the analog channels in the demo
driver. The frequency of the sine wave depends on the configured sample rate of
the demo device. The frequency of the sine wave is always 20 times smaller than
the sample rate, in other words we always have 20 samples per period.
CC libsigrok_hw_common_la-usb.lo
usb.c:241:18: warning: no previous prototype for 'usb_thread'
[-Wmissing-prototypes]
SR_PRIV gpointer usb_thread(gpointer data)
^
usb.c:256:13: warning: no previous prototype for 'usb_callback'
[-Wmissing-prototypes]
SR_PRIV int usb_callback(int fd, int revents, void *cb_data)
^
The sample rate on the Hameg scopes changes depending on the number of channels
turned on and on the current timebase.
Update the sample rate if any of the above change.
The current vertical division setting (per channel) and the timebase are stored
as a floating point number. This is suboptimal since clients expect us to send
this information to them in form of a rational number.
Store only the index of the current setting since all the supported settings are
already stored inside of an array.
The DF_END packet was send out after all configured frames were fetched, but
devices may stop the acquisition at any point in time and an DF_END will not be
send out in this case.
Send the DF_END packet inside of acquisition_stop() so this can't happen.
The device is after a scan left open and clients that don't call unconditionally
dev_open() will never fetch the initial device state.
Close the device after the scan so clients know they need to open it.
Most of the supported gear uses the ANSI C locale for communication, and if the
client sets up an incompatible locale parsing would fail.
This function ignores the client's locale and parses floating point numbers
using the ANSI C locale. This function should be always used when parsing
floating point numbers coming from the instrument.
With drivers that support multiple devices we need to know the device model
while listing options. That information is most of the time saved in the private
part of the dev_inst structure.
Pass the pointer to the dev_inst structure as an function argument so we have
access to this information.
parse_size_string() incorrectly parses a real number, e.g. 1.5 kHz ends up
being 1Hz.
This patch fixes parse_size_string() to take the fractional part as well into
account. The fractional part is parsed as an double precision floating point
number while ignoring the locale.
(lwla_setup_acquisition): Set the clock divider bypass
flag to 1 for the external clock modes as well.
(capture_setup): Set the clock divide count to 0 if an
external clock source is selected.
(lwla_send_bitstream): Unref the mapped file earlier in order
to simplify the error handling.
(lwla_receive_reply): Do not treat a reply buffer length of
zero as silent no-op. That logic was left over from an earlier
iteration, before the distinction between reply buffer size and
expected read length was introduced.
(lwla_set_clock_source): Checking whether an enum value is greater
than or equal to zero apparently results in a warning with some
compilers. Assign the enum to an unsigned variable to avoid this,
and return SR_ERR_BUG if the range is exceeded, as this indicates
a bug in the driver code itself.
The g_ascii_formatd() function expects the "format" argument to start
with a '%' character, e.g. it should be "%f" or such (this is not
clearly documented in the glib API docs, but visible from the source code).
The usage of "CH%f" for example will trigger an assertion and thus make the
LWLA device unusable in practice (e.g. in PulseView on Windows no probenames
would be shown, and sampling wouldn't work).
Example:
GLib-CRITICAL **: g_ascii_formatd: assertion 'format[0] == '%'' failed
(not exposed in all glib versions or builds of glib on all distros
apparently, some may need G_MESSAGES_DEBUG=all or other measures)
From the glib g_ascii_formatd() code:
g_return_val_if_fail (format[0] == '%', NULL);
We now use g_snprintf() instead for simplicity. This has been tested to
fix this specific issue (i.e. the probenames now do show up in PulseView).
This closes bug #270.
The current implementation is renamed to tcp-rigol as it seems to be
a Rigol proprietary protocol used only on Rigol VS5000 series.
A new tcp-raw implementation is introduced which simply carries raw SCPI
commands over TCP. It is probably a much more common protocol and it is
at least available on Rigol DS2000 series on port 5555.
This allows a frontend to initialize a session file, providing the
required samplerate and probe names, without having a proper
struct sr_dev_inst handy.
sr_session_append() is then used to add captured data to the session
file, as usual.
The existing sr_session_save() function works the same way as always.
Most messages from the DMM parsers are not hard errors, lower to
sr_dbg() so that the sigrok-cli output doesn't get cluttered (by default)
with debug output such as:
P1: 0.001100 V DC AUTO
sr: fs9721: Sync nibble in byte 0 (0x00) is invalid.
P1: 0.001100 V DC AUTO
(using -l 4 or -l 5 will still allow the user to see such messages)
The sample buffer is a still a bit of a mystery, but this should help.
The variables in play:
triggerbar/ramsize_trigger - These two variables added together indicate
how many samples we want captured. ramsize_trigger - triggerbar
indicades how many samples must be captured. The ratio between the two
is determined by capture ratio.
memory_size - This indicates the number of samples in the circular
capture buffer. stop_address, now_address, and trigger_address are
pointers within the zeroplus that wrap based on this size.
now_address - The address that the zeroplus was about to write to when
it finished capturing, and now the address that will be read from when
reads are done from the capture buffer
stop_address - The address that the zeroplus last wrote to when it
completed capture.
trigger_address - The sample address for which the trigger occured.
status - This one is a bit tricky. Some testing has shown that if the
zeroplus has captured memory_size or less samples, the STATUS_READY bit
is set. For all captures generated with more samples than this,
STATUS_READY was cleared. However, boundary conditions are difficult to
test and values such as, memory_size + 1 have not been tested. We use
this to determine if the capture has wrapped through the sample buffer.
More testing is required, but this improves behavior in a number of
cases, specifically capturing sample amounts that are not a power of 2
of the sample buffer size. Before, random data was passed to libsigrok.
Signed-off-by: Russ Dill <Russ.Dill@gmail.com>
Experimentation with the windows driver has found no situation where
this is set to anything other than 1. The zerominus software also never
sets this to anything other than one. Revert the code change made in
0ab0cb942f.
Signed-off-by: Russ Dill <Russ.Dill@gmail.com>
If there is no trigger, don't try to capture anything before it. There
won't be any because we trigger immediately.
Signed-off-by: Russ Dill <Russ.Dill@gmail.com>
This will need some additional work when support is added for compression
modes since group D is disabled for RLE compression and C and D are
disabled for "double" compression.
Signed-off-by: Russ Dill <Russ.Dill@gmail.com>
We have to wait a bit longer than 1s for a valid DMM packet to arrive,
since for various DMMs some modes (Hz/% for example) the packets will
arrive a lot less often than in other modes. If the waiting period is
too short detection of the DMM will fail.
CC libsigrok_hw_gmc_mh_1x_2x_la-protocol.lo
protocol.c:133:32: warning: equality comparison with extraneous
parentheses
[-Wparentheses-equality]
} else if ((devc->scale1000 == 2)) {
~~~~~~~~~~~~~~~~^~~~
protocol.c:133:32: note: remove extraneous parentheses around the
comparison to
silence this warning
} else if ((devc->scale1000 == 2)) {
~ ^ ~
Here is what the datasheet says about this:
"If judge bit is 1, it means frequency mode. If judge bit is 0,
it means duty cycle mode."
But this is plain wrong. Reality proves this is the other way around.
Depending on the chip, the limit value for the buzzer is between 25 and 35 Ω,
so this code set the limit for continuity to 25 Ω to be on the safe side.
This fixes the following warning:
asix-sigma.c: In function 'receive_data':
asix-sigma.c:1064:4: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
devc->state.lastts = *(uint16_t *) buf - 1;
^
This also makes the diff from Doxyfile to Doxyfile_internal more readable.
Also, put public API docs into doxy/html-api/, private stuff into
doxy/html-internal/.
This gets us the libusb version checking mechanism itself, hopefully
making this sort of thing easier in future.
Also hotplug, device tree traversal, and lots of fixes.
This is helpful in many cases, e.g. when trying to identify which of the
16000 system error codes from
http://msdn.microsoft.com/en-us/library/ms681381%28VS.85%29.aspx
has been encountered (which is not trivial if you only have an,
e.g. German, string message alone).
The GError object has to initialized to NULL before being passed to
g_file_set_contents or it will throw the following critical warning
GLib-CRITICAL **: g_file_set_contents: assertion 'error == NULL || *error == NULL' failed
and return FALSE, which leads to failed assertion and subsequently
to the test failing
This reworks the triggerbar/trigger address logic to match the values sent
by the windows app for all models (The zerominus tool was used to reprogram
the USB device ID on a single device). Additionally, the DONT_CARE_TRIGGERBAR
register is always set by the windows app and does not seem to indicate that
these registers are "don't care"'s.
While captures using a trigger do set the STATUS_READY bit, immediate
captures do not set the STATUS_READY bit, they just clear the STATUS_BUSY
bit. This was confirmed with packet captures using the "official" driver/app.
Reading a frame over the DS1xx2 RS232 connection now sometimes works,
but most of the time stalls part way through with g_poll showing the
fd as not ready.
This patch adds a function for a common operation of all serial based drivers.
It extracts the serial options from the options linked list that is passed down
to every hardware driver.
This patch adds a function to read and parse a SCPI response which contains a
comma separated list of unsignet 8-bit integer numbers (e.g "1,0,64").
This is particularly useful if the instrument sends digital measurement data
in this format.
This patch adds a function to read and parse a SCPI response which contains a
comma-separated list of floating-point numbers (e.g. "1.0e-5,2.0e-4,3.0e-3").
This is particularly useful if the instrument sends analog measurement
data in this format.
The SCPI standard specifies the "*OPC?" command (Operation complete query) which
queries the instrument for its operative state. When all pending operations are
complete, the instrument responds with a "1".
Some manufacturers block before completing all operations and don't respond
with anything and some of them respond with a "0". This function handles both
cases uniformly.
This patch adds helper functions to read an SCPI response and parse the response
as an integer, boolean, floating-point or double-precision floating-point number.
The Standard Commands for Programmable Instruments (SCPI) defines a standard
for syntax and commands to use in controlling programmable test and measurement
devices.
SCPI documentation:
http://www.ivifoundation.org/docs/scpi-99.pdf
This patch adds helper functions for sending SCPI commands, reading a SCPI
response and reading and parsing a SCPI "*IDN?" response.
This patch adds helper functions for converting a string to different number
formats (double, long, float, int).
These functions are exposed in the public API.
SR_CONF_PATTERN_MODE was not handled in config_list(), yielding
non-working OLS support in PulseView (due to an assert), and a missing
pattern list in sigrok-cli's --show output.
This fixes bug #184.
The fields of this structure should not be used directly by frontends
(and none of the current ones do). Thus, make the struct opaque and hide
its contents from the API.
The text output module keeps buffers for internal state, upon receiving a DF_END
packet it frees the internal context but the buffers are never freed.
This adds a text_cleanup() helper function and registers it as the cleanup
function within all the text output modules.
The scan() function was opening the port in non-blocking mode, the dev_open()
function however was not using the SERIAL_NONBLOCK flag. This led to hangs
in certain situations.
This fixes the OLS e.g. on NetBSD.
A new sp_port is created every time we call serial_open (sp_get_port_by_name
implicitly creates one for us), so free it every time we call serial_close.
Without a SR_DF_END samples could be cached in the internal buffer of an output
module and never flushed, therefore they would be missing in the final output.
By sending a SR_DF_END packet we force the output to be flushed.
Disable drivers that need serial port support if libserialport is not found.
Also, disable building various other serial port related code in that case.
The libtool current:revision:age numbers change from 1:1:0 to 1:2:0
(i.e., revision is increased) since the library source code has changed,
but no interfaces were added or changed or removed.
Details:
http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info
This changes the library filename (e.g. on Linux) from libsigrok.so.1.0.1
to libsigrok.so.1.0.2, but the SONAME (+symlink) remains the same
(libsigrok.so.1) since this release is API- and ABI-compatible with the last.
The bandwith in Rigol DS1xx2D/E scopes can be upgraded to 150 MHz in software.
So detect also scopes with the upgraded bandwith.
using libsigrok-0.2.1 + this change + commit da970d24ec (required for newer kernels):
[dan@eagle sigrok]$ sigrok-cli --scan -d rigol-ds1xx2 -l 5
sr: libsigrok loglevel set to 5.
sr: Sanity-checking all drivers.
sr: Sanity-checking all input modules.
sr: Sanity-checking all output modules.
srd: libsigrokdecode loglevel set to 5.
sr: hwdriver: Initializing driver 'rigol-ds1xx2'.
sr: serial: Opening serial port '/dev/usbtmc0' (flags 1).
sr: serial: Opened serial port '/dev/usbtmc0' (fd 7).
sr: serial: Wrote 5/5 bytes (fd 7).
sr: serial: Closing serial port /dev/usbtmc0 (fd 7).
sr: rigol-ds1xx2: response: /dev/usbtmc0 [Rigol Technologies,DS1152D,DS1EU150XXXXXX,00.04.01.00.02]
sr: hwdriver: Scan of 'rigol-ds1xx2' found 1 devices.
The following devices were found:
rigol-ds1xx2 - Rigol Technologies DS1152D 00.04.01.00.02 with 18 probes: CH1 CH2 D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15
FreeBSD's libusb-1.0 compatible library has a few differences compared
to the "normal" libusb-1.0 from libusb.org which we have to work around.
LIBUSB_CLASS_APPLICATION doesn't exist in FreeBSD's libusb, and
libusb_handle_events_timeout_completed() doesn't exist either.
The latter is basically libusb_handle_events_timeout() with an extra
(unused by us) parameter, so the workaround is relatively simple.
This fixes bug #185.
Most Metex DMMs use e.g. " mV" as unit field, others use "mV ",
though. Support these (and other) whitespace variants by stripping all
spaces and only comparing non-space characters.
We now use zip_int64_t and zip_get_num_entries() for example, which
requires at least libzip 0.10. This version was released in 03/2012,
which is old enough that we don't necessarily have to do a work-around
for older versions. Thus, simply bump the requirement to >= 0.10.
If buf contains exactly the string "Agilent Technologies" (for example if
there are bugs in the timeout logic or serial driver causing the reply from
the meter to be abridged) then this code will SEGV. This is because tokens[1]
is NULL but only tokens[2] and tokens[3] (both of which are undefined) are
NULL checked.
Can be trivially corrected by NULL checking tokens[1] as well.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
g_usleep(XX) sleeps for *at least* XX microseconds but may sleep for
longers (on older kernels the sleep will typically be 10000us). Thus
byte receive loops containing an unconditional sleep will perform
very poorly (for example it causes the scan in agilent-dmm to timeout
prematurely).
Even on modern kernels serial_readline() has a 2ms sleep per byte which
means it will read at a maximum rate of half a character per millisecond
(~4800baud).
This is fixed by only sleeping when read() returns no data.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
This extends the session file format to contain logic data files named
either "logic-1" as before, or "logic-1-1", "logic-1-2", ...
representing chronologically ordered chunks of captured data.
The chunks are transparently concatenated together by sr_session_load().
This exposes the list of devices added to the session. In the case of
loading a session from file, these struct sr_dev_inst are otherwise
not exposed to the frontend. See bug 145.
This DMM is not using the standard bits in the FS9922 protocol/structure
to indicate the "volt" and "diode mode" flags. Instead, it only sets the
user-defined bit "z1" to indicate both "diode mode" and "volt".
This fixes#142.
This is no longer used, and also it is not available on Android and thus
breaks cross-compilation for Android.
Thanks Marcus Comstedt <marcus@mc.pp.se> for reporting.
For demux mode we half the channels. Previous check method broke
the OLS randomly and but it in a bad state.
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
demux mode allows DDR sampling which disables group 2 & 3
and thus samples group 0 & 1 to sample on rising and falling of
the clock.
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
Allow channel groups to be swapped. This is useful
for demux at 200mhz with the unbuffered channels.
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
The high bit of the sample, denoting this is a count, was not getting
properly cleared. This resulted in an inevitably negative count, and
corruption of the sample buffer before it was transferred to the
frontend.
The single sample buffer, up to 4 bytes long, was not getting initialized
on (every) acquisition start, only after the first full sample was in.
This caused the first sample to potentially hold garbage.
ols allows both external and internal test patterns at ~20khz
which are helpful for unit tests and demos.
pattern=internal -> route pattern internally to all 32 pins
(input otherwise disabled)
pattern=external -> generates pattern on unbuffered pins 16:31
(which can be looped back to the buffered pins 0:15)
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
Stage count was always getting incremented one more than
actual stages, and this caused a extra stage with zero'ed data
probe lines to have the start bit field.
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
The map_eeprom_data function is currently unknown. The map entries
provided were observed via bus-snooping of the vendor software on my
device. Other devices may need additional values.
Since the uni-t-ut32x series handles devices with the same USB VID.PID,
which is linked to the WCH CH9325 USB/HID-UART interface chip, this
driver can no longer assume it can handle anything with this VID.PID.
The last release (0.2.0) had the libtool version (current:revision:age)
set to 1:0:0. Since this release doesn't add/change/remove any
interfaces, only 'revision' is increased, resulting in 1:1:0.
http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info
Frontends using libsigrok don't need to be recompiled or relinked.
The boundary test-case with SR_GHZ(18446744073ULL) currently fails, but
that is not practically relevant so comment it out for now, until we add
a proper fix.
The function previously formatted 1004 as 1.4 k and 1004000 as 1.4 M.
The function now formats 1004 as 1.004 k, 1004000 as 1.004 M and
1004000000 as 1.004 G.
Fixes#73.
The udev rules file should only list devices that are actually supported
by a driver in the current libsigrok version. Thus, drop all entries for
devices which will get support later on (at which point the respective udev
rule will be re-added again).
Also, add a few missing entries.
The Tecpel DMM-8060 was added since we assumed it would be a rebadged
Voltcraft VC-820 (since we know the Tecpel DMM-8061 is a rebadged VC-840).
However, according to the vendor webpage it doesn't have PC connectivity
at all, so drop it for now (until someone can confirm that it does or does
not actually have RS232/USB connectivity).
Can't really count on it either way though, the device is just
too flaky to conclude whether it's going to work or not, regardless
of the status returned.
The per-driver API calls no longer have a hw_ prefix (e.g. hw_init()
became init() and so on), so drop the 'hw_' from the std versions
for those API callbacks too.
The comment for the CSV output module says probes are ordered e.g.
0,1,2,3, but the actual values were in the 3,2,1,0 order.
We're fixing this by making the order of the probe values 0,1,2,3 too
for now, but this will become a configurable option later on.
Thanks Patrick Servello <patrick.servello@gmail.com> for the patch.
Triss
Frank Stettner
Gerhard Sittig
Ralf
Daniel Anselmi
Sylvain Pelissier
Rafael G. Martins
Soeren Apel
Helge Kruse
Petteri Aimonen
litospain
waka
Florian Ragwitz
Alberto Scotta
HReimann
Richard Allen
v1ne
Peter Skarpetis
Niklas Thorne
Timo Kokkonen
Ben Gardiner
Jiri Slaby
Florian Schmidt
Earle F. Philhower, III
milan hauth
Mike Walters
Wolfram Sang
Uwe Hermann
Valentin Ochs
motte
Andy Lutomirski
Walter Goossens
Anatol Pomozov
Andreas Sandberg
Tobias Faeth
Sergey Rzhevsky
Richard
Jan Metzger
Christian Fruth
Peter van der Perk
Tom Matthews
Elen Eisendle
Juan M. Bello-Rivas
Daniel Trnka
David Sastre Medina
jirjirjir
Martin Ling
Dave Buechi
Marc Jacobi
Michał Janiszewski
Adrian Godwin
Peter Åstrand
Sylvain Munaut
Marc Schink
Derek Hageman
Stefan Brüns
Kate J. Temkin
Jan Luebbe
Sebastian Reichel
Miklos Marton
Guido Trentalancia
Nadav Mavor
Andreas Piesk
Vitaliy Vorobyov
Gerd v. Egidy
Dewelde Anthony
Thomas Andres
Michael Klengel
Wolfram Sang
majekw
Mike Williams
Paul
Sven Bursch-Osewold
Jon Burgess
luftek
Thomas Weißschuh
marchelh
Peetz0r
Andrej Valek
Eva Kissling
Matthias Schulz
Adrian Stratulat
Joerg Alpers
JohnCh
Bastian Schmitz
Sergey Alirzaev
Mandl
James Churchill
Axel Hinrichs
Romain Tartière
Philipp Marek
Andreas Zschunke
Michał Janiszewski
Holger Müller
Timo Rothenpieler
Joel Holdsworth
Kumar Abhishek
Marcus Comstedt
turboaffe
Jan Luebbe
Roland Hieber
Angus Gratton
Johannes Römer
Gwenhael Goavec-Merou
Marc Schink
Karl Palsson
Bert Vermeulen
Jan Losinski
Sven Schnelle
Matthieu Guillaumin
Vlad Ivanov
Sebastian Tabares Amaya
Aurelien Jacobs
Vlad Ivanov
Karl Palsson
Vadim A. Misbakh-Soloviov
Mike Meyer
Karsten König
Erik Montnemery
Sebastian Zagrodzki
Benjamin Larsson
Thomas
Yasushi SHOJI
Lars-Peter Clausen
Alexandru Gagniuc
George Hopkins
Diego Asanza
Marvin Schmidt
Markus Siegert
Andrew Bradford
EJ
Martin Ling
Chriter
Daniel Elstner
Tilman Sauerbeck
Hannu Vuolasaho
Matthieu Gaillet
jry
Karl Palsson
Bartosz Golaszewski
Martin Lederhilger
Scott Allen
Daniel Glöckner
Hubert CHAUMETTE
Daniel King
Daniel Lezcano
Daniel Gröber
Carl-Fredrik Sundström
Jiří Pinkava
eightdot
Baruch Even
Vladislav Ivanov
Uffe Jakobsen
Daniel Elstner
Mathias Katzer
Janne Huttunen
Rene Hopf
Vincent Palatin
Tim Hatch
Jens Steinhauser
Matthias Heidbrink
Peter Zotov
magnuskarlsson
Dan Horák
Mike Frysinger
Marek Vasut
poljar (Damir Jelić)
Matthias Heidbrink
Fabio
Russ Dill
poljar (Damir Jelić)
Sean Young
Daniel Thompson
Matt Ranostay
Peter Stuge
Paul Sokolovsky
Florian Knodt
Florian Steinhardt
