OK, anyway, I finally dared to just give it a try and the result was pretty much perfect with default settings on Avery 3552 transparencies. I just somewhat underestimated the work to remove all these tiny sticking bits. Just two hints from my side for people trying on Win 7 64bit 1) It's important to use only 64bit versions (or only 32bit, but not mixed). E.g. I first installed Ghostscript in a 32bit version by mistake which resulted in weird error messages. 2) At least in my case, no Silhouette printer was shown in the System Control's printer tab - only some default USB printer support. Silhouette Studio still worked but to share the printer in the network, you need a proper printer driver installed. I finally found it hidden on the Silhouette site: http://www.silhouetteamerica.com/faq/so ... er-concern
I finally got gerber2graphtec to create the output file under Win7 without warnings. I'm using Python 2.7.8, Ghostscript 9.16, pstpedit 2.70 and GerbV 2.6.1. Didn't try to cut yet but I find it a little scary that the created temporary PDF seems to be missing the upper 1 or two millimeters. See attachment - it's the "fine_pitch_sampler" example. Any ideas? Or is this normal?
Some small issues I detected lately when using OLSFront again: When saving/restoring the whole configuration (*.olsf) manually edited channel names seem to get lost. In the trigger menu, when switching from advanced to simple trigger, sometimes the whole tab is empty and you need to switch to advanced mode and back to be able to see something. Side note question: I understand the "Demon Core" style advanced triggers are still not implemented and the current "advanced" trigger modes are not that advanced at all. Is there any chance to see a trigger menu for the Demon Core triggers? And is there any documentation for the current "advanced" trigger modes? E.g. what unit does the "delay" have? When is it applied (e.g. before advancing to the next stage)?
The "invert CS" works as expected. I also had a quick look at the javascript parser for SPI. Looks fascinatingly simple. I guess it should be easy to write e.g. a SENT decoder. Nice. Also I must admit that I overlooked the quick-measurement feature via the shift key. Very nice - just a true period measurement (e.g. falling egde to falling edge) is missing in the currently available alpha.
A bit of competition is always nice and I must admit I also like OLSFront quite a bit. Unfortunately, I fail to see where you attached the parser, so I can't try.
BTW: what I miss a bit in OLSFront is that automatic period/frequency measurement mode that the OLS GUI offers. Also I must admit I like the color configuration possibilities of the OLS GUI as one color for all the channels looks a bit boring. What I really like about OLSFront is the display of the decoded information and I also think the "Decoded" window is a good idea. Then again, switching the decode style of an existing decoder doesn't seem to be possible. Not even simple stuff as decoding in dec instead of hex. I figure I need to delete the protocol decoder and add a new one with different settings!? Also displaying MISO and MOSI data alternating is a bit confusing. Maybe it would make more sense to have to columns or even two tabs in the decode window.
Ah, I see, I overlooked I can increase a channel's height via the channel settings. Dumb me ;) Maybe it would make sense to have a global setting for this in the preferences.
One second thought about the cursors: it is a great feature that decoding is only done between cursors 1 + 2 (?), but maybe it would make sense to have an option like "decode only between cursor 1+2" somewhere so you could also disable this.
I also observed one more issue in this context: if the CS is the very first (rising) edge in the recorded data (which is not so unlikely if you used it as trigger and set the before/after ratio to 0), this first SPI communication is not decoded, no matter if you activate "honor CS" or not. Only if you activate the "invert CS" or use the cursors and move cursor 1 to a negative time position, the first message will be decoded. As a side note: the selection of "invert CS" doesn't seem to be stored when closing the SPI analyzer window. If you open it up the next time, it is not selected any more.
Oops. I wasn't even aware that the cursors had an influence on decoding. Working fine now ;) Thanks again for your great support.
BTW: it's just a minor and optical issue, but is there any chance to get a better looking decoding again? In the older versions of the GUI, the decoded information looked somewhat nicer. Also now that I tried OLSFront, I must say that I like its way of displaying the decoded information without covering the raw data better. In the OLS GUI, the raw data is always somewhat occluded, no matter if I use top/bottom or center as location. Also it would be a nice feature for OLS GUI to configure the display style of the decoded information (hex, decimal, binary, hex + ASCII etc.).
BTW2: dunno what led me to the "OLG" typo. The "G" is no even close on the keyboard. Must have been sleepy...
Thanks again for your quick reply. I downloaded "ols-0.9.8-SNAPSHOT-full.zip" and tried again, but while there is now an option to invert the chip select, unfortunately the outcome is more or less the same (see appended screenshot). Again, "honour /CS" doesn't seem to make much of a difference. And yes, I guess you can use the file as a test case. Even though it's pretty uncommon (very low speed and inverted CS). I guess I could offer a more interesting example (with normal low active CS though).
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.
[quote author="EasyRider"]What you seem to be describing is not really an issue - it's how RLE works. ... And yes, I am aware that more byzantine schemes can be devised that make better use of memory for smaller bit widths, but I assume the current implementation targeted simplicity (and frugality, since the advanced triggers take up lots of FPGA resources) rather than memory economy.[/quote]
Ok, that makes sense. I kinda implied a more sophisticated approach and wasn't aware that the compression scheme is that simple. I must object though that this is not how RLE works, but this how this (very simplistic) approach implements RLE. It's good to know though how it works, so I can better adjust the number of channels to the use case.
In the meantime I figured I have a v1.04 hardware with a Winbond flash. For some reasons "ols-loader" identified my Winbond flash correctly while the other tools didn't
ols-loader.exe -p:COM6 -selftest Logic Sniffer ROM loader v0.3 (November 9, 2010) Opening serial port 'COM6' @ 921600 ... OK Found OLS HW: 1, FW: 3.0, Boot: 2 Found flash: WINBOND W25X40 done... Passed self-test :)
I just wonder why nobody cared to update the tools and scripts to support the Winbond flash without any tricks as it seems to be in production for some months now...
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:
So finally I can post without without being forced to watch every dot...
[quote author="jawi"]I'm still here, alive and well! :)[/quote] That's good to hear :)
[quote author="jawi"]The only thing is that my spare time is a bit sparse at the moment, so I cannot work as much on the OLS client as I would like to. So progress is a bit slow at the moment...[/quote] Sounds familiar ;)
[quote author="jawi"]Hmm, what version of my client are you running? I've not heard of this problem before, so could you supply me with some additional information?[/quote] Client is 0.9.4 from the OLS 3.0.8 release. Starting via the exe works ok (but only for the non-expert download), but running the batch from the jawis-ols-client folder gives the following error message:
Fehler: Hauptklasse C:devOpen Logic Snifferols-0308jawis-ols-client\binorg .apache.felix.configadmin-1.2.8.jar konnte nicht gefunden oder geladen werden
Which means that the main class couldn't be found or loaded. Indeed when looking inside the batch, it tries to run a class file directly:
Yet in the bin folder there are only jars, no single class files. [quote author="jawi"]I've created an issue on GitHub for this to be implemented: https://github.com/jawi/ols/issues/78.[/quote] Great, thanks!
[quote author="jawi"]Unfortunately not. As I've written above, my time is a bit sparse at the moment to implement this functionality... :([/quote] Yeah, I kinda assumed this. Yet I don't give up hope yet... It's not that I needed it right now. But it would be pretty sweet to have these good old HP LA triggers and there are indeed some situations where I needed something like this.
[quote author="jawi"]I'm currently rewriting the display component, which includes support for grouping any number of channels. Would this fit your requirement?[/quote] This sounds like a very good start. Of course the idea of a bus is also that you can define trigger patterns on the bus and show the decoded value of the binary pattern that the bus represents at a given time. I think at least the latter should be easy to implement, as something like this is already there for the 8ch groups.
[quote author="jawi"]Hmm, not seen this behavior before. I'll try to reproduce it myself, and see whether a immediate fix is needed in the old display component.[/quote] I think it only happens with large recording when pressing "zoom to original level" directly after a capture/loading or after pressing "zoom to best fit". E.g. I can reproduce it for a record length of about 20s, when sampling 16ch at 10MHz without any signals connected and RLE enabled: I uploaded a long empty buffer you you to reproduce it (just open the OLS file, then press "zoom to original level"): http://http://home.arcor.de/0xdeadbeef/empty.ols
[quote author="jawi"]This is already requested, see: https://github.com/jawi/ols/issues/10 Thanks for your bugs and feature requests! I'll really try to do my best to implement them as soon as possible...[/quote] Great.
