Hello, thank you for your work and help.

On 04/05/16 01:33, Uwe Hermann wrote:
> There's no point IMHO to try to add their "native" LA support btw. Just
> using the button on the device will switch the VID/PID to something that
> works out of the box with fx2lafw and is *much* more usable than the
> "native" 6022BL LA support for that device.
>
Quite agree, although we loose 8 channels.

>> This is followed by an immense series of errors which I presume to be a
>> consequence of the first. The compiler supports c++11 and the flag is
>> activated.
>
> Hm, looks strange indeed. Can you file a bug at sigrok.org/bugzilla
> please, so we'll keep track of this?

I will, but suggest we make some progress to be more objective on the 
bug report, read below.

> Also, try --disable-ruby and see if that is a usable workaround for the
> time being (unless you want to use the Ruby bindings, of course).

Indeed you are right, --disable-ruby allowed the build without errors.
But it was just the start of other problems, the first having nothing to 
do with sigrok. In fact, in arclinux aur repositories, the 
sigrok-firmware-fx2lafw  does not pull the last snapshot and so, it 
doesn't have support for hantek 6022.

So, I edited the PKGBUILD, pulled the last snapshot, built and installed.

Plugged the scope, nothing happened, the red led stays quiet.

$ lsusb
Bus 001 Device 009: ID 04b4:602a Cypress Semiconductor Corp.

So, included you z60_libsigrok rules that I've found somewhere, and 
adapted for the 6022BL, including TAG+=uaccess:

# Hantek 6022BE
#ATTRS{idVendor}=="04b4", ATTRS{idProduct}=="6022", MODE="664", 
GROUP="plugdev", TAG+="uaccess"
#ATTRS{idVendor}=="04b5", ATTRS{idProduct}=="6022", MODE="664", 
GROUP="plugdev", TAG+="uaccess"

# MyMod Hantek 6022BL
ATTRS{idVendor}=="04b4", ATTRS{idProduct}=="602a", MODE="664", 
GROUP="plugdev", TAG+="uaccess"
ATTRS{idVendor}=="04b5", ATTRS{idProduct}=="602a", MODE="664", 
GROUP="plugdev", TAG+="uaccess"

But of course this only authorizes access, does not load the firmware, 
and again nothing happened.

$ lsusb
Bus 001 Device 009: ID 04b4:602a Cypress Semiconductor Corp.

So, I included the openhantek udev rules (90-hantek.rules), also with 
some touches:

# Hantek DSO-6022BE
#SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", 
ENV{PRODUCT}=="4b4/6022/*", RUN+="/sbin/fxload -t fx2 -I 
/opt/git-repos/openhantek/fw/hantek6022be-firmware.hex -s 
/opt/git-repos/openhantek/fw/hantek6022be-loader.hex -D $env{DEVNAME}"
#ATTRS{idVendor}=="04b5", ATTRS{idProduct}=="6022", MODE="0666", 
GROUP="plugdev"

# Hantek DSO-6022BL
#SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", 
ENV{PRODUCT}=="4b4/602a/0", RUN+="/sbin/fxload -t fx2 -I 
/opt/git-repos/openhantek/fw/hantek6022be-firmware.hex -s 
/opt/git-repos/openhantek/fw/hantek6022be-loader.hex -D $env{DEVNAME}"
#ATTRS{idVendor}=="04b5", ATTRS{idProduct}=="6022", MODE="0666", 
GROUP="plugdev", TAG+="uaccess"
#SUBSYSTEM=="usb", ATTRS{idVendor}=="04b4", ATTRS{idProduct}=="6022", 
MODE:="0666", GROUP="plugdev", TAG+="uaccess"
#SUBSYSTEM=="usb", ATTRS{idVendor}=="04b5", ATTRS{idProduct}=="6022", 
MODE:="0666", GROUP="plugdev", TAG+="uaccess"

And also included de firmware:
$ ls -l /opt/git-repos/openhantek/fw
total 20
-rw-r--r-- 1 root root 14042 Oct  5  2015 hantek6022be-firmware.hex
-rw-r--r-- 1 root root  2304 Oct  5  2015 hantek6022be-loader.hex

Commented out the sigrok udev rules, reload udev, plugged the scope:
The red led starts blinking and goes off after a couple of seconds, and:
$ lsusb
Bus 001 Device 010: ID 04b5:6022 ROHM LSI Systems USA, LLC

Please notice 04b5:6022, as 6022BE, not 04b5:602a as 6022BL.

Then launched Pulseview which now recognizes Hantek 6022BE and show two 
identical traces on CH1 and CH2 of about 1KHz and 5V peak-peak, centered 
around 0 Volt (so AC), at 500mV vertical range. The odd thing is that I 
have nothing connected to the inputs. If I do, nothing changes.

Changing the input range to 1V, changes de amplitude to 10Vpp, the 
inverse of what it should be.

Well, I guess we made some progress, at least we have a trace (actually 
two), although being wrong.

I wonder if this is related to the openhantek firmware being different 
form ours?

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel

Reply via email to