Marek Vasut [Sun, 20 Apr 2014 19:34:36 +0000 (21:34 +0200)]
asix-sigma: Remove stack-based alloc in download_capture()
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.
Marek Vasut [Sun, 20 Apr 2014 18:50:10 +0000 (20:50 +0200)]
asix-sigma: Localize variables
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.
Marek Vasut [Sun, 20 Apr 2014 18:45:40 +0000 (20:45 +0200)]
asix-sigma: Move all register I/O into download_capture()
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.
Marek Vasut [Sun, 20 Apr 2014 18:40:00 +0000 (20:40 +0200)]
asix-sigma: Clearly separate the sample download
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.
Marek Vasut [Sun, 20 Apr 2014 18:30:16 +0000 (20:30 +0200)]
asix-sigma: Pull out the CAPTURE mode handler
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.
Marek Vasut [Sun, 20 Apr 2014 17:57:02 +0000 (19:57 +0200)]
asix-sigma: Read position only in CAPTURE state
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.
Marek Vasut [Sun, 20 Apr 2014 17:36:40 +0000 (19:36 +0200)]
asix-sigma: Pull out the logic-mode switching
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.
Marek Vasut [Sun, 20 Apr 2014 17:19:33 +0000 (19:19 +0200)]
asix-sigma: Cleanup the bit2bitbang
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.
Marek Vasut [Sun, 20 Apr 2014 15:58:35 +0000 (17:58 +0200)]
asix-sigma: Weed out in-condition assignments
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.
Marek Vasut [Sun, 20 Apr 2014 15:49:29 +0000 (17:49 +0200)]
asix-sigma: Fix firmware path construction
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.
Marek Vasut [Sun, 20 Apr 2014 15:18:31 +0000 (17:18 +0200)]
asix-sigma: Cleanup FPGA initialization
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.
Marek Vasut [Sun, 20 Apr 2014 15:02:05 +0000 (17:02 +0200)]
asix-sigma: Remove NUM_CHANNELS macro
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.
Uwe Hermann [Fri, 25 Apr 2014 16:40:59 +0000 (18:40 +0200)]
Don't include LOG_PREFIX in the Doxygen output.
(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.
fx2lafw: fix possible use of uninitialized variable (gcc-4.9 warning fix)
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");
^
Uwe Hermann [Sun, 30 Mar 2014 23:26:07 +0000 (01:26 +0200)]
la8: Add support for the ChronoVu LA16.
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).
Uwe Hermann [Fri, 14 Mar 2014 20:09:37 +0000 (21:09 +0100)]
Replace 'probe group' with 'channel group' everywhere.
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.
Uwe Hermann [Wed, 19 Mar 2014 22:04:55 +0000 (23:04 +0100)]
Switch to a non-recursive automake setup.
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.