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.
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.
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.
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.
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.
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>
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.
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>
Gerhard Sittig
Uwe Hermann
Daniel Trnka