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