This DMM is not using the standard bits in the FS9922 protocol/structure
to indicate the "volt" and "diode mode" flags. Instead, it only sets the
user-defined bit "z1" to indicate both "diode mode" and "volt".
This fixes#142.
The Tecpel DMM-8060 was added since we assumed it would be a rebadged
Voltcraft VC-820 (since we know the Tecpel DMM-8061 is a rebadged VC-840).
However, according to the vendor webpage it doesn't have PC connectivity
at all, so drop it for now (until someone can confirm that it does or does
not actually have RS232/USB connectivity).
The per-driver API calls no longer have a hw_ prefix (e.g. hw_init()
became init() and so on), so drop the 'hw_' from the std versions
for those API callbacks too.
- Explicitly list .config_get in all drivers for consistency, and set it
to NULL if unused (whether or not a driver implements it is optional).
- List all 'struct sr_dev_driver' entries in the same order in all drivers.
- Move the check whether .config_set/.config_list exist (i.e., are non-NULL)
into sanity_check_all_drivers().
This is a small helper function which sends the SR_DF_HEADER packet that
drivers usually emit in their hw_dev_acquisition_start() API callback.
It simplifies and shortens the hw_dev_acquisition_start() functions
quite a bit.
It also simplifies the input modules which send an SR_DF_HEADER packet, too.
This patch also automatically removes some unneeded malloc/free in some
drivers for the 'packet' and 'header' structs used for SR_DF_HEADER.
Check the relevant arguments for != NULL before calling the actual
driver-specific function, so that the driver can safely assume those
arguments are non-NULL. This removes the need to duplicate these
checks in every driver.
Sending an SR_DF_META packet at the start of every stream is not
mandatory; the frontend should ask for what it needs, and any extra
information the driver wants to send will come in due time.
This matches the _ser suffix of the other functions/variables for this
device ("ser" denotes that it is used with the serial UNI-T UT-D02 cable
as opposed the USB/HID based cables which are handled by the uni-t-dmm driver).
But more importantly, the _SER suffix for the enum value will prevent
name clashes later, when the uni-t-dmm driver gets a VOLTCRAFT_VC820 enum.
Do the same for VOLTCRAFT_VC840.
Check whether a sample limit was actually set (> 0) before checking if
that sample limit is reached. This also fixes continuous acquisition mode
for drivers which have that.
Implement SR_HWCAP_LIMIT_MSEC capability, to allow acquisition to automatically
stop after a specified amount of time.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
serial-dmm does not check if a sample limit is actually in place before deciding
to stop acquisition. Since the sample limit is set at 0 by default, operating
in continuous mode will cause acquisition to stop before even sending the first
sample.
Check to make sure we actually are in a sample-limited mode before stopping for
this reason.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This works with the UNI-T UT-D02 (RS232) cable. For the USB/HID
based cable (UNI-T UT-D04), the uni-t-dmm driver must be used.
Note: This is untested, but should work just fine for all settings, with
the possible exception of temperature (testers needed!)
Just use the 'int dmm' + wrapper method that is used for all other
functions which need this information. There is no real need to
special-case the hw_dev_acquisition_start() API call here.
The rs9lcd parser, which is used for the RadioShack 22-812 does not use its
*info parameter, and therefore did not have a rs9lcd_info struct declared.
With recent re-factoring of the receive data callbacks, it became necessary to
pass a struct pointer. This made the RECV_DATA macro look like:
- RECV_DATA(RADIOSHACK_22_812, metex14)
giving the wrong impression that the RadioShack 22-182 uses the
metex14 protocol, which is not the case.
Create a dummy rs9lcd_info struct, and correctly identify the parser
as rs9lcd in the RECV_DATA macro:
+ RECV_DATA(RADIOSHACK_22_812, rs9lcd)
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Not all drivers use subdrivers. The only reason the subdriver field was
introduced was to accomodate the model of serial-dmm.
The sr_dev_driver struct is available to the frontend. Exposing the subdriver
field creates the problem of exposing knowledge of libsigrok's internal driver
layout, even though the drivers are designed to be a flat list to the frontend.
Store the subdriver in the dev_context struct of serial-dmm.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The global *di alias was used to keep track of the driver context.
It caused issues with trying to use several subdrivers at once, so
its use was obsoleted.
The correct context is preserved through different mechanisms, either
the *sdi pointer, or wrappers which pass the correct context.
The *di alias is no longer used, so remove it.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Uwe Hermann
Florian Knodt
Florian Steinhardt
Bert Vermeulen
Alexandru Gagniuc