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 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 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>
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 ]
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>
Gerhard Sittig
Uwe Hermann