commit 378abfeac6 tried to solve a bug where
the fx2lafw driver would print "Device came back" even if a timeout had occured.
It solved that issue, but inadvertently introduced a new bug:
"Device came back" would be printed even if no firmware upload was performed.
This is counterintuitive, as the device is only reset when a firmware upload is
performed.
There are three cases:
i) Firmware upload was successful
ii) Firmware upload failed
iii) Firmware upload was NOT needed
Each case warrants a separate message from the driver. Print the
following messages depending on the outcome:
i) "Device came back"
ii) "Device failed to renumerate"
iii) "Firmware upload was not needed."
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Use the new DRIVER_LOG_DOMAIN mechanism, where explicitly writing
the driver name in the message string is no longer required.
Thus:
- sr_err("fx2lafw: Something bad happened.");
becomes:
+ sr_err("Something bad happened.");
In either case, the log output is the same.
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>
Wrappers for hw_init, hw_cleanup, clear_instances, and hw_scan are needed for
each subdriver due to the nature of serial-dmm. These wrappers are implemented
as macros, in order to reduce the number of lines of code.
For each of those functions, we have a separate wrapper list, then we connect
them together in a first-class driver using a DRV macro, and yet another list
(the DRV list).
Instead of declaring those wrappers in separate lists, include them in the DRV
macro. This approach reduces the number of macro lists from five to just one.
From the perspective of adding a new subdriver, this also greatly reduces the
number of places needed to hook in a new device.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Store/use the receive_data() function and a pointer to the driver struct
in the dmms[] array. Use a ".subdriver" entry in the driver struct.
Use a macro to simplify hw_init() wrappers.
Declare dmm_info dmms as extern in protocol.h to prevent duplicate
symbol error from the linker.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
di was initialized as NULL. If no device covered by this driver
is used, di remains NULL. This causes a segmentation fault when
calling clear_instances().
Check for di being NULL.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Use the infrastructure of serial-dmm to handle the RadioShack 22-812,
and completely remove radioshack-dmm.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Move the parsing part of radioshack-dmm into a separate protocol
parser, following the model from hardware/common/dmm.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
During scan the serial port is opened with SERIAL_RDONLY | SERIAL_NONBLOCK,
which works fine, but when acquisition starts, it is opened only with
SERIAL_RDONLY. On Linux, if cdc_acm can make a claim to the USB to serial
converter, opening the port will fail.
Open port with SERIAL_RDONLY | SERIAL_NONBLOCK.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
We already have an event-based mechanism in place. Using a thread just
adds unneeded complexity, especially for a driver designed not for
performance, but for providing a testbed to frontends.
Generate the data in the event handler, not in a separate thread.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
strcmp(buf + 9, " mA") does not work because buf is CR-terminated,
while " mA" is NUL-terminated.
Drop ambiguities arising from the termination of the strings, and
only compare the characters we care about, using strncmp().
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
When the parser found a space, it treated it as an invalid digit
and discarded the whole packet. This behavior was incorrect on
2000 count devices, where the first digit can be sent as a space
rather than a '0'.
Convert spaces to '0' and parse them as usual.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Prepare the tekpower-dmm driver to be able to support various simple
serial port based DMMs.
Also, make a 'tekpower-tp4000zc' "first-class" driver which is currently
the only user of this generic driver.
The demo driver was using sr_session_source_add_channel() to add
a poll source, but was relying on sr_session_run_poll() to call
sr_session_source_remove(). This, coupled with the design of the
driver caused errors once the samples were collected.
The error stream was most likely related to failing to properly close
one of the channels.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This is the first step in fixing the demo driver: figuring out what is
being called and what is not _and_ have it show up in the logs.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Options in addition to the usual "9600/8n1" syntax start with a
slash, and take the form of key=value, where different options are
also separated by slashes. For example:
"9600/8n1/rts=0/dtr=1"
This sets RTS low and DTR high.
The packet mode byte is akin to a signature. If that is invalid, there's
no point in calculating the checksum, so check the mode first.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Serial detection was using serial_readline, which stripped carriage
return from the packets. This made for a very unreliable detection
mechanism.
Switch to a timeout-based detection mechanism that parses the data
as it comes in. This also allows us to stop parsing once we found
our first valid packet.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
ols driver used to probe a series of available serial ports obtained
by regexp matching of common serial port names.
There are a number of problems with this approach:
1. It will probe all serial devices, including devices that do not
like to be probed, potentially causing them to act up.
2. It will try to probe serial ports which may already be opened in
other applications for other purposes.
3. It assumes the naming of the serial ports is set in stone, and
creates an unnecessary OS-specific list.
4. It produces unnecessary debug output even when an OLS device is
not connected.
5. etc...
Do not implicitly probe serial ports. Only probe the port specified
by the frontend, if any; otherwise, just quit.
Also get rid of all functionality in serial.c which was designed
specifically for random probing.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
In the case of USB drivers, a driver's dev_acquisition_stop() cannot
simply remove its fd sources from the session and close its devices:
a USB transfer might still be underway, and it needs to be finished
(and its memory freed) properly.
An sr_dev_inst->status value is added: SR_ST_STOPPING, which should
be set when the driver's dev_acquisition_stop() is called, and acts
as a marker for the USB event handler to wind up its operations.
In order for dev_acquisition_stop() to be able to set the sdi status,
however, it needs to be unconstified.
- Default to 1MHz.
The default sample rate is the lowest frequency (100Hz),
but it takes a very long time until 128K memory is full.
- Fix the 1MHz setting.
- Use samplerate list.
- Fix 10MHz frequency.
- Fix trigger.
- Change the size of memory according to the number of samples.
- Add pre-trigger (capture ratio) setting.
- Fix the first acquisition after power on.
Move sr_usb_connect() and sr_usb_open() to hardware/common/usb.c in a
slightly more generic form and add more error checks and logging.
Let genericdmm use the new/moved functions.
Merge parts of the tekpower-dmm code (the chip of the TekPower
TP4000ZC seems to be an FS9721_LP3 too) and rework parts of the functions.
Adapt the tekpower-dmm and uni-t-dmm code accordingly.
So far, it seems we can make this work with just hw_init() needing to
be subdriver-specific (it will point 'di' to the respective per-subdriver
entry), the rest of the API functions can then use a strcmp() on di->name to
learn which subdriver they belong to.
The 'uni-t-dmm' driver/directory will not appear as a "driver" to
frontends anymore, it's just an internal thing.
The frontends will see a uni-t-ut61d and voltcraft-vc820 driver now,
with the correct names and parsers etc. attached to them.
This is not fully finished yet, but it's a start (and works mostly):
$ sigrok-cli -D
The following devices were found:
UNI-T UT61D with 1 probe: P1
Voltcraft VC-820 with 1 probe: P1
$ sigrok-cli --driver voltcraft-vc820 -D
The following devices were found:
Voltcraft VC-820 with 1 probe: P1
$ sigrok-cli --driver uni-t-ut61d -D
The following devices were found:
UNI-T UT61D with 1 probe: P1
# Now attaching a UNI-T UT61D device via USB.
$ sigrok-cli --driver uni-t-ut61d --samples 3 -O analog
P1: -0.017800 V DC
P1: -0.017600 V DC
P1: -0.017700 V DC
# Now attaching a Voltcraft VC-820 device via USB instead.
$ sigrok-cli --driver voltcraft-vc820 --samples 3 -O analog
P1: -0.319200 V DC
P1: -0.319300 V DC
P1: -0.319300 V DC
Alexandru Gagniuc
Uwe Hermann
Bert Vermeulen
Joel Holdsworth
Peter Stuge
Toshiaki Yoshida