Add support for the Pepino-style of accessing >256K of memory. Because
this the only known extension of accessing >256K currently, we apply it
as soon as the sample size is bigger than 256K. Let's hope other
devices (if any) will follow this style. If not, we need to add support
depending on the device name later.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Magnus (creator of the Pipistrello) confirmed that he mixed up the
register names. The code was doing it correctly nonetheless but was
confusing to read because of this. Fix it to make it easier to
comprehend.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Let max_channels really carry the number of maximum channels the
hardware supports. We will handle the limitation of only half the
channels available in 200MHz mode later. Note that there won't be a
regression because we only set the variable but never check it. The
desired result of this patch is the removal of the NUM_CHANNELS macro.
The number of channels needs to be dealt with at runtime.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
We needs this twice so put it into a seperate function, so updates to it
will automatically handled for both callers.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
commit f51acd69 ("ols: combine demux samples") wrongly replaced the bit
pattern of 0x20 with the number of channels which just happens to be 32
as well. So, the code works but is confusing to read. Reword the
for-loop to make it more comprehensible.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The OLS protocol sends 16bit values to specify the sample count and
delay count. However, this 16bit value is the number of 32bit words to
be sampled, so the actual sample count is 4 times larger and does not
fit into a uint16_t. Extend it to support the full range of 256K
(LogicShrimp will need this) and to prepare support for devices with
even more memory (Pepino).
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The previous implementation assumed that a receive data chunk ends
exactly with a sensor packet's end. Yet the buffer had 32 bytes while
the packets have 19 bytes.
Separate the data reception from the packet processing. Collect whatever
chunks the USB connection provides, and scan the resulting buffer for
packets. Cope with either incomplete or corrupt or misaligned packets as
well as with multiple packets in receive chunks. The latter might happen
upon initial synchronization, when a device already sends data or the
serial port buffered previously communicated data.
In the regular case, the computer will process so fast that each single
character will be handled individually. We don't mind. The frequency is
some 60 times per second, and the data volume is 19 bytes. The software
works for the regular case, and synchronizes fast at startup or after
comm errors.
Always print the data bytes of received buffers in the packet parser,
then check some more fixed fields to not process invalid packets, then
process the packet content as the previous implementation did.
Call the packet parser for incomplete packets and discarded input
buffers as well (initial synchronization, re-sync after comm errors).
This results in the availability of more diagnostics during development.
Pass the packet's location and size from outside. This prepares the
logic to cope with situations where the receive buffer contains multiple
(potentially incomplete) packets.
Slightly unobfuscate the UT32x packet parser. The protocol is mostly
ASCII based, checks for hex numbers may be unexpected. Use symbolic
identifiers for the packet length and some special characters.
The previous implementation of the UT32x driver expected to see a conn=
spec, without it no device is found. Default to the USB identification
of the CH9325 chip, to make the driver work out of the box. Users still
can provide conn= specs and override the default for other cables.
Slightly rephrase README.devices since there is no strict distinction
into "fully automatic" and "always manual". Some drivers _accept_ conn=
specs when provided, _and_ support automatic detection of enumerable
devices, _and_ might implement defaults but also support overrides.
Nit, numerically sort the list of Uni-T cables (which is about to grow
in the future) for improved readability.
Add two more devices which require users to manually enable the serial
communication (Brymen BM257s, EEVBlog 121GW).
Fill in the scan, open/close, get/set/list, acquisition start/stop logic
such that data acquisition with a PICkit2 works.
Trigger support needs more attention. User specified triggers either
seem to not take effect, or the trigger position is not in the expected
location. It's yet to get determined what's the issue.
This implementation is based on protocol information gathered from the
pk2-la project.
Remove a free() call in an error path for a list which immediately
before the call was determined to be NULL. Use index 0 and 1 for
channels P1 and P2 respectively (the previous implementation used 0
for both channels).
The current implementation of the SCPI DMM driver is conservative about
checking the device's being operational, but the *OPC? queries are found
in unfortunate locations. Run the OPC query right before running the
next "actual" command, not afterwards. And certainly not between sending
requests and potentially gathering responses in subsequent calls.
This commit does not change current behaviour, but improves maintenance
before pending commits.
The "get MQ" helper routine communicates SCPI responses and translates
them to internal "MQ and flag" values. Optionally return the MQ table
entry reference to callers, so they don't have to repeat the table
lookup when the function's default precision is required, or should
future "start acquisition" requests need to refer to the meter's current
function.
Uwe Hermann
Thomas Andres
Michael Klengel
Frank Stettner
Daniel Anselmi
Wolfram Sang
Gerhard Sittig
Martin Ling
majekw
Mike Williams
Paul