The chronovu_la8 input module is capable of handling either file type,
generated by LA8 or LA16 vendor software. Automatic detection is not
available, but user provided channel counts work fine.
Adjust the input module's name and description, and claim support for
.kdt as well as .kd1 files.
Add developer notes on implementation details, the file content's
constraints, and potential future adjustment.
The file format is funny, a data part is leading (fixed size) and a
"header" part follows. The previous implementation sent the header part
to the session, too, pretending it was part of the data. This change
limits the number of samples that get sent to the session.
Comment on the file layout and header fields while we are here. This
information got lost in commit 02e24c0ce0 when the input module got
converted from do-it-yourself file operations to having intrinsic
handler routines invoked from common logic which handles the file.
Although the file format handled by this input module appears to be of
fixed size (8MiB plus 5 more bytes), it's more reliable to use a data
type for the file size that is larger than "an int". Although off_t
would be most portable, use uint64_t to match the code which passes the
parameter to the input module.
When users don't specify the input format, applications can try to have
the format auto-detected. Some of the tests were weak and could result
in false positives.
Add a 'confidence' parameter to the input modules' format_match()
method. Claim high confidence (1) for those formats which can check
magic strings or the presence of essential keywords (vcd, wav). Claim
medium confidence (10) for those formats which happened to mis-detect
inputs in the past (trace32_ad). Claim weak confidence (100) for those
formats which totally lack reliable conditions and rather guess than
detect (chronovu_la8).
Prefer the best match in public scan routines. Return at most one module
to callers even if multiple modules matched, to keep the current API.
This addresses part of bug #1200.
Some of the standard helper functions take a log prefix parameter that is
used when printing messages. This log prefix is almost always identical to
the name field in the driver's sr_dev_driver struct. The only exception are
drivers which register multiple sr_dev_driver structs.
Instead of passing the log prefix as a parameter simply use the driver's
name. This simplifies the API, gives consistent behaviour between different
drivers and also makes it easier to identify where the message originates
when a driver registers sr_dev_driver structs.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
This makes the code shorter, simpler and more consistent, and also
ensures that the (same) debug messages are always emitted and the
packet.payload field is consistently set to NULL always, etc.
Since Autoconf places some important feature flags only into the
configuration header, it is necessary to include it globally to
guarantee a consistent build.
Move the include flags for files in the source tree from
configure.ac to Makefile.am where they belong. Also use
AM_CPPFLAGS instead of CFLAGS/CXXFLAGS to make sure the
files in the build/source tree are always picked up first.
Also, remove the include/libsigrok sub-directory from the
search path, thereby making the <libsigrok/> prefix mandatory
when building libsigrok itself. This matches the convention
already imposed on users of the library.
This signifies to the module instance no more input will come. This
will cause the module to process any data it may have buffered. The
SR_DF_END packet will also typically be sent at this time.
When an input module instance has received enough input to fully
populate the struct sr_dev_inst, sdi_ready is set to TRUE and its
receive() method returns immediately. Any remaining received data
is buffered until the next time the function is called.
SR_OK: a match was found.
SR_ERR: no match.
SR_ERR_DATA: a match was found but the module cannot handle the input.
SR_OK_CONTINUE: some module didn't have enough data to be sure.