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>
Bert Vermeulen
Matthias Heidbrink
Uwe Hermann
Martin Ling
Marcus Comstedt
Marek Vasut