If buf contains exactly the string "Agilent Technologies" (for example if
there are bugs in the timeout logic or serial driver causing the reply from
the meter to be abridged) then this code will SEGV. This is because tokens[1]
is NULL but only tokens[2] and tokens[3] (both of which are undefined) are
NULL checked.
Can be trivially corrected by NULL checking tokens[1] as well.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
g_usleep(XX) sleeps for *at least* XX microseconds but may sleep for
longers (on older kernels the sleep will typically be 10000us). Thus
byte receive loops containing an unconditional sleep will perform
very poorly (for example it causes the scan in agilent-dmm to timeout
prematurely).
Even on modern kernels serial_readline() has a 2ms sleep per byte which
means it will read at a maximum rate of half a character per millisecond
(~4800baud).
This is fixed by only sleeping when read() returns no data.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
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.
This is no longer used, and also it is not available on Android and thus
breaks cross-compilation for Android.
Thanks Marcus Comstedt <marcus@mc.pp.se> for reporting.
For demux mode we half the channels. Previous check method broke
the OLS randomly and but it in a bad state.
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
demux mode allows DDR sampling which disables group 2 & 3
and thus samples group 0 & 1 to sample on rising and falling of
the clock.
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
Allow channel groups to be swapped. This is useful
for demux at 200mhz with the unbuffered channels.
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
The high bit of the sample, denoting this is a count, was not getting
properly cleared. This resulted in an inevitably negative count, and
corruption of the sample buffer before it was transferred to the
frontend.
The single sample buffer, up to 4 bytes long, was not getting initialized
on (every) acquisition start, only after the first full sample was in.
This caused the first sample to potentially hold garbage.
ols allows both external and internal test patterns at ~20khz
which are helpful for unit tests and demos.
pattern=internal -> route pattern internally to all 32 pins
(input otherwise disabled)
pattern=external -> generates pattern on unbuffered pins 16:31
(which can be looped back to the buffered pins 0:15)
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
Stage count was always getting incremented one more than
actual stages, and this caused a extra stage with zero'ed data
probe lines to have the start bit field.
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
The map_eeprom_data function is currently unknown. The map entries
provided were observed via bus-snooping of the vendor software on my
device. Other devices may need additional values.
Since the uni-t-ut32x series handles devices with the same USB VID.PID,
which is linked to the WCH CH9325 USB/HID-UART interface chip, this
driver can no longer assume it can handle anything with this VID.PID.
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).
Can't really count on it either way though, the device is just
too flaky to conclude whether it's going to work or not, regardless
of the status returned.
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.
Uwe Hermann
Daniel Thompson
Matt Ranostay
Bert Vermeulen
Marcus Comstedt
Florian Knodt
Marc Schink
Florian Steinhardt