While it's not typical, there are cases where a device uses a high active chip select for SPI. No matter what I tried though, it seems impossible to decode an SPI signal with high active CS in the OLS GUI no matter whether I enable "honor /CS" or not. It's the same in all versions of the client software, even in the newest RC. I tried OLSFront then and while it also doesn't allow me to use a high active CS or invert the channel for decoding, it at least allows me to select an unused (low) channel as CS and then decodes everything correctly.
However, with the OLS client not even this is possible. Whatever I try, I alway end with "Tool failed. Details: No CS start-condition found!"
So would it be at least possible to ignore the CS if "honor /CS" is disabled? Of course it would be nicer if it would be possible to use a high active CS. Or on a more global level: if it would be possible to invert signals in the main view, I could invert the CS signal there and the option wouldn't be needed in the SPI decoder.
Hm, I seem to have a similar problem. In a brand new OLS, I can upgrade the FPGA bitstream via COM6 without any issues. However upgrading the PIC always fails. I installed the drivers from the 3.0.8 package on two different PC, one with Win7 64bit and one with XP 32bit, and the behavior is the same.
The main issue probably is that there is no USB device detected at all, just the virtual COM port. So is this maybe a driver issue? The drivers in the 3.0.8. release (dpinstx64.exe and dpinstx86.exe) report as 2.1.0.0.
Edit: I investigated a bit and tried the pumploader utility, but it can't detect the flash for some reason:
I'd really love to use the advanced trigger options that the Demon Core offers. And while the FPGA code was obviously finished in March, there is still no clue when it will be possible to actually use these new trigger options. So any news regarding this topic?
It doesn't seem to be possible currently to define a bus as in other LA applications. Instead only a probe channel can serve as a hard coded 8bit bus. Are there any plans to change this?
When pressing "Zoom to original level" directly after a capture, the screen redraw always freezes (grey screen) until you scroll or zoom.
A zoom window would be nice. Maybe it would make sense to allow to toggle between the dragging feature and a zoom window.
I got my OLS today and played around with it a little bit. I installed the newest client (3.0.8.) and updated the firmware(s) to the newest version(s) (OLSv1.firmware.v3.0.hex, logic_sniffer_3.07-Demon-Core.bit).
Apart from some quirks (OLS_Upgrader.bat expect COM6, but my OLS installed as COM9, upgrader didn't find the HW in the first N trials, client had connection issues and then crashed etc., the scripts use non-existing Linux shell commands under Windows etc.) I could get it to run.
Then again, there seem to be some issues with the 200MHz sampling and the RLE. So while starting the capture with no trigger conditions works for 10 and 100MHz without any issues, it doesn't work for 200MHz: here the OLS behaves as if it's waiting for a trigger conditions, although there is none...
Also the behavior of the RLE confuses me a little: E.g. with RLE enabled and 16 channels, you can sample for about 20s at 10MHz if there are no edges at all. However if you reduce the channels to 8, only 156ms are sampled under otherwise exactly equal conditions. With 8 channels, there are 24k per channel, so without compression, you can sample for 2.4576ms. Enabling RLE increases this to about 156ms, so the compression factor under ideal conditions is only 64:1. Then again with 16 channels, there are 12k per channel -> without compression you can sample for 1.2288ms. Enabling RLE increases this to about 20s (!), which means a compression factor of about 16384:1. So why exactly does the maximum recordable time decrease by a factor of 256 when 16 channels are used instead of 8?
