Regular operation of serial DMM drivers optionally can dump packet bytes
after the intialization phase has synchronized to the stream. Failure to
synchronize to the stream left developers without a dump, which complicates
research what went wrong.
Do dump packet content while the serial_stream_detect() routine tries to
synchronize to the stream. Use the spew level since the dump occurs upon
every attempt, which translates to: every received byte until a valid
packet was seen (or the synchronization phase expired).
The previous implementation always dumped 23 data bytes for received
packets. This could result in truncated diagnostics information, and/or
access to invalid buffer content.
Rephrase the packet dump routine such that the specific meter's exact
packet length gets dumped, and use the common hex dump support code.
Introduce common support for hex dumps in the string util collection.
There are explicit allocation and release routines for the textual
representation of the data bytes, so that callers are free to chose
whether and how to decorate the dump and where to send the message.
Keep (part of) previous results around when the VCD input module gets
reset, and check the header of the next import against previous runs to
avoid issues in applications. This addresses the VCD specific part of
bug #1241, and resolves the remaining part of bug #1306.
Applications are not prepared to handle changes in the channel list
between multiple acquisitions from the same source (device drivers
or input modules). Introduce common helpers to compare channels and
channel lists.
There was the sr_channel_new() allocation routine, but releasing that
allocation was open-coded in call sites. Add the sr_channel_free()
routine for code re-use and consistency.
This addresses part of bug #1306. The reset() method of the VCD input
module was incomplete, and did not process new data upon second read.
Improve robustness and add missing reset instructions. Void invalid
pointers and avoid NULL dereferences in cleanup paths.
Example:
In file included from src/hardware/kecheng-kc-330b/protocol.h:26,
from src/hardware/kecheng-kc-330b/api.c:22:
src/hardware/kecheng-kc-330b/api.c: In function ‘config_list’:
src/libsigrok-internal.h:51:34: warning: division ‘sizeof (void *) / sizeof (void)’ does not compute the number of array elements [-Wsizeof-pointer-div]
#define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
^
src/libsigrok-internal.h:55:32: note: in expansion of macro ‘ARRAY_SIZE’
#define ARRAY_AND_SIZE(a) (a), ARRAY_SIZE(a)
^~~~~~~~~~
src/libsigrok-internal.h:964:43: note: in expansion of macro ‘ARRAY_AND_SIZE’
std_opts_config_list(key, data, sdi, cg, ARRAY_AND_SIZE(scanopts), \
^~~~~~~~~~~~~~
src/hardware/kecheng-kc-330b/api.c:296:10: note: in expansion of macro ‘STD_CONFIG_LIST’
return STD_CONFIG_LIST(key, data, sdi, cg, NULL, drvopts, devopts);
^~~~~~~~~~~~~~~
Default to the existing "P1" etc naming scheme for analog channels of
serial-dmm subdrivers. Add support for subdriver specific channel names
(which can reference the channel number if they desire). This is useful
for devices with multiple displays, or special purpose devices where
other names than P1 can better reflect the channel's nature.
Commit 556a926d43 introduced support for multiple displays in
subdrivers of serial-dmm, but also changed user visible channel numbers
to start from 0. Restore the previous behaviour, start counting from 1
which users may perceive as more natural (serial-dmm used to start at P1
in the past, scopes start with CH1 as well).
There are code paths where dev_close() tries to access a USB handle
which does not exist. This was observed with this command:
$ sigrok-cli -d brymen-bm86x --scan
On Windows, this device can either enumerate as 04b4:602a or 04b5:602a,
depending on which vendor driver is currently being used, so we have to
support both in the hantek-6xxx driver as well.
This fixes bug #1295.
In the case where the input unit was not in the array, the for loop would
complete, but the following test would then read past the end of the array
since 'i' would already have been incremented to the array size.
Spotted because unitless data was getting SI prefixes with no unit, though
this would not have been deterministically reproducible.
This fixes parts of bug #950.
The comment says "A requested value is certainly on the way", but the code no
longer works this way. The receive handler requests a value and blocks until
it is received. There is no value pending between receive handler calls, so
this code now only leads to a timeout.
Applications might pass NULL for the buffer, and input modules might
accept it (or just cope). Eliminate a potential NULL dereference in
the emission of diagnostics messages.
On Windows, this device can either enumerate as 04b4:6022 or 04b5:6022,
depending on which vendor driver is currently being used, so we have to
support both in the hantek-6xxx driver as well.
This fixes bug #918.
This is happening because the send() and recv() functions
have different prototypes on POSIX and Windows. Using the casts
is required on Windows and doesn't hurt on POSIX systems.
[...]/protocol.c: In function 'tcp_send':
[...]/protocol.c:161:26: warning: pointer targets in passing argument 2 of 'send' differ in signedness [-Wpointer-sign]
out = send(tcp->socket, buf, len, 0);
^
In file included from [...]/protocol.c:24:0:
[...]/include/winsock2.h:997:34: note: expected 'const char *' but argument is of type 'const uint8_t * {aka const unsigned char *}'
WINSOCK_API_LINKAGE int WSAAPI send(SOCKET s,const char *buf,int len,int flags);
^
[...]/protocol.c: In function 'ipdbg_la_tcp_receive':
[...]/protocol.c:201:32: warning: pointer targets in passing argument 2 of 'recv' differ in signedness [-Wpointer-sign]
int len = recv(tcp->socket, buf, 1, 0);
^
In file included from [...]/protocol.c:24:0:
[...]/include/winsock2.h:992:34: note: expected 'char *' but argument is of type 'uint8_t * {aka unsigned char *}'
WINSOCK_API_LINKAGE int WSAAPI recv(SOCKET s,char *buf,int len,int flags);
^
[...]/protocol.c: In function 'data_available':
[...]/protocol.c:73:38: error: 'bytes_available' undeclared (first use in this function)
ioctlsocket(tcp->socket, FIONREAD, &bytes_available);
^
[...]/protocol.c:73:38: note: each undeclared identifier is reported only once for each function it appears in
[...]/protocol.c:84:1: warning: no return statement in function returning non-void [-Wreturn-type]
}
^
The fx2lafw(4) driver supports mere logic analyzers as well as mixed
signal devices, but does not support channel group specific device
options. Avoid an error message when channel group device options get
queried, the condition is perfectly legal and non-fatal.
How to reproduce:
$ pulseview -d fx2lafw
$ sigrok-cli -d fx2lafw -g Logic --show
This fixes bug #1267.
The "firmware load failed" message would be even more helpful if users
could learn which firmware file failed to load. Add those filenames to
various FX2-based drivers.
This addresses bug #1262.
Gerhard Sittig
Uwe Hermann
Peetz0r
Martin Ling
Andrej Valek
Soeren Apel