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>
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.
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.
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.
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.
Marek Vasut
Bert Vermeulen
Uwe Hermann
Aurelien Jacobs
poljar (Damir Jelić)
Matthias Heidbrink
Fabio
Matthias Heidbrink
Daniel Elstner
Martin Ling