(just my guess on reported run_state's)
my assumption is that run_state 0x85e_2_ is meaning "waiting for trigger
condition".
from your other log output i see that there is no edge/level-trigger
requested, device should just start sampling 200M samples no matter what
signals are applied...
and
hi helge,
TL;DR: can someone help helge with creating a usb trace on windows?
attached is a log file from running the command
sigrok-cli -l 5 -d kingst-la2016 --samples 200M -O binary -o test.bin
on my linux machine (debian kernel 4.19.0-2-amd64 with debian's
libusb-1.0-0 version 1.0.22 on
I doubt that the USB pass through is fast enough, but I will give it a try.
I found that the driver libsigrok/src/hardware/kingst-la2016/protocol.c
sends one of two commands:
unknown_cmd1_340
unknown_cmd1_342
depending on the firmware file size. The name of the variables suggest that
the
Hey!
On Tue, Oct 27, 2020 at 02:30:42PM +0100, Helge Kruse wrote:
> I am not sure what configuration should be set here. I would be interesting
> to see a successful operation with that device on a Linux PC hardware. Could
> you generate a similar log with "sigrok-cli --scan" and send it to me?
I have built with cross-compiler mingw for the target platform (Windows). I
have patched the mentioned fragment to ignore the error in
libusb_set_configuration. With this change I am able to upload the firmware.
But the driver doesn't receive any data from the device. (see kingst.log)
The patch
Hi Uwe, hi sigrok team,
Just a reminder - I've submitted this fix for FX2 based scopes already
half a year ago.
If you do not like the extra frequencies, please correct at least the
100, 1000 and 1 Hz values, 50 kHz doesn't work with 12 MHz CPU clock.
Easy fix: The settings of RCAP2 must
6 matches
Mail list logo