On Tue, 2019-09-24 at 11:07 +1000, Stuart Longland wrote: > > [ ... toggling GPIOs to mark code paths ... ] > > I've got `sigrok-cli` to capture 4 channels at 25MHz (any faster and > it gives up, despite the device being able to "stream" at 100MHz). > I've run 6 tests; 3 with hardware crypto enabled, and 3 without, and > saved the VCD dumps from `sigrok-cli`.
The sigrok-cli application is not threaded, while the Pulseview application is. So the choice of (all of) the acquisition device, the processing, and output format all contribute to the maximum throughput. It could be that sigrok's native .sr format is a better choice than VCD (haven't checked, but I know how expensive it is (at the application side) to do the "compression" for VCD, which may or may not compare well to what a ZIP library does. The GUI application won't suffer from that limitation, and usually copes with higher data rates since acquisition and display are threaded, acquisition goes to RAM, and storing to disk is a separate activity. About the acquisition bandwidth: It's commonly assumed that there is a limit around 200Mbps when you communicate via USB to an FX2 based device. So I'd question the 100MHz capability (to local storage OK, but not streaming, unless some kind of hardware assisted compression is involved). > Now VCD is simple enough that I've been able to rough up some > scripts to analyse these, but the "there must be a better way" > thought is still nagging me to keep looking around. > > Specifically, I want to be able to compare two waveforms > side-by-side, and gather some stats like how wide a given pulse is > or how much time a signal has been sampled in a given state. Did you try the "timing" decoder which tells you the distance among edges? Or the "pwm" decoder which tells you the duty cycle of a signal? You'd probably want the combination of the two. And even if you can't get a single window with multiple (independently recorded) traces in them, you can use multiple windows in Pulseview and arrange them as you like. They won't scroll in lock step, but that can also be a desired behaviour if the start is not synchronized. Alternatively whip up a script which combines .sr files' content into another .sr file (there is none in mainline). > PulseView can import a VCD, but doing so is a recipe for watching my > workstation grind to a halt until OOMkiller sorts it out. (A > similar foot-gun is setting the sample rate and period too high.) > > I suspect PulseView may be trying to load the entire raw file into > memory: "decompressing" the changes and thus generating the original > raw samples. 40 seconds worth of 4-bit 25MHz samples is quite a lot > of data and I'm not sure how PulseView represents it internally -- > perhaps that is worth looking at. That's known behaviour, due to a conscious design choice -- you cannot navigate as easily over data that's stored in compressed form, so raw samples are kept in RAM and on-disk files get compressed. For VCD it's usually caused by insanely high sample rates and thus resulting "timescale" specs in the .vcd file. I wish those who generate VCD files (including sigrok I guess) would declare more appropriate values. Can you provide example data? At least the start of the file if the complete data is too large. My guess is that 25MHz sample rate results in a 1ns timescale which translates to 1GHz "data rate". The VCD spec is limiting here, but should allow to use a 100MHz spec instead, thus reducing the data volume by an order of magnitude. Which could unbreak your use case (do the math, a byte each 10ns for 40s duration, should be around 4GiB instead of 40GiB plus the OOM). There is experimental code in https://repo.or.cz/libsigrok/gsi.git/shortlog/refs/heads/wip/output-vcd-timescale if you want to have a look. Please report back if it works for you, this can increase the probability of mainline accepting the change. virtually yours Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
