I'm in the market for a USB LA, and I was reading a
review on the Saleae Logic Pro 8, and one thing that was mentioned was that it does not have continuous triggering. If this means what I think it means, this absolutely blows my mind. I had been completely taking for granted that I could grab just about any LA on the market, hook it up to my SPI accelerometer dev board (for example), trigger on the CS# line, and watch the waveforms and decoded data change/morph* on screen as I twist and turn the accelerometer, just like I can with my Rigol DS2202 oscilloscope (albeit with insufficient channels). Have I misunderstood, or is that really
not a reasonable expectation for any LA?
* in that typical oscilloscope way
The Saleae products are not real-time. They bulk stream raw data over USB for search/post-processing. Collect data, then decode/search through it.
Logic analyzers are used for data capture and analysis. I can't imagine what value an "auto-run" would ever have.
I'm in the market for a USB LA, and I was reading a review on the Saleae Logic Pro 8, and one thing that was mentioned was that it does not have continuous triggering. If this means what I think it means, this absolutely blows my mind. I had been completely taking for granted that I could grab just about any LA on the market, hook it up to my SPI accelerometer dev board (for example), trigger on the CS# line, and watch the waveforms and decoded data change/morph* on screen as I twist and turn the accelerometer, just like I can with my Rigol DS2202 oscilloscope (albeit with insufficient channels). Have I misunderstood, or is that really not a reasonable expectation for any LA?
* in that typical oscilloscope way
Hum that could be quite the feature I guess, if one can read and decode visual logic levels in USB real-time?
Logic analyzers are used for data capture and analysis. I can't imagine what value an "auto-run" would ever have.
Apart from the accelerometer example I just stated in the OP? Go on, how do I figure out which of the 3 axes is which without having the screen live updating while I move the accelerometer around?
Another contrived example, you're fiddling with a trimmer on the mixed analog/digital board until the SPI stream from the ADC reads a particular target value? Hey, with a bunch of coding the uC on said board could offer an actual calibration feature, but what if that's not ready yet? Also, flexing the board and looking for glitches live?
I'm debugging an issue at the moment where the interrupt pin is not operating as I expect on my accelerometer. With my 4 channels on the oscilloscope, I can just re-upload my code as I experiment with different register settings, and the updated waveforms appear live on screen. I partially want this LA to give me more than 4 channels, but as soon as I get the LA, I have to whack the single-shot button repeatedly? Why?
I mean, I think of a logic analyzer as a 1-bit, 16-channel oscilloscope. I find it bizarre to suggest that this slight change in specs suddenly renders auto-run pointless. Is there a third kind of device that fills my usecases?
Logic analyzers are used for data capture and analysis. I can't imagine what value an "auto-run" would ever have.
HP logic analyzers have had auto-run forever. I mean, the 1630s had it, and that stuff is early 80s.
By "auto-run," I think what he means is, "at a trigger condition, display everything and re-arm the trigger." It's really no different from a 'scope triggering in Normal mode but not in one-shot. Also the trigger condition could be don't-care ('scope auto-trigger), but that isn't very useful.
Logic analyzers are used for data capture and analysis. I can't imagine what value an "auto-run" would ever have.
Apart from the accelerometer example I just stated in the OP? Go on, how do I figure out which of the 3 axes is which without having the screen live updating while I move the accelerometer around?
Another contrived example, you're fiddling with a trimmer on the mixed analog/digital board until the SPI stream from the ADC reads a particular target value? Hey, with a bunch of coding the uC on said board could offer an actual calibration feature, but what if that's not ready yet? Also, flexing the board and looking for glitches live?
I'm debugging an issue at the moment where the interrupt pin is not operating as I expect on my accelerometer. With my 4 channels on the oscilloscope, I can just re-upload my code as I experiment with different register settings, and the updated waveforms appear live on screen. I partially want this LA to give me more than 4 channels, but as soon as I get the LA, I have to whack the single-shot button repeatedly? Why?
I mean, I think of a logic analyzer as a 1-bit, 16-channel oscilloscope. I find it bizarre to suggest that this slight change in specs suddenly renders auto-run pointless. Is there a third kind of device that fills my usecases?
Sounds like a mixed signal scope is what you want.
Sounds like a mixed signal scope is what you want.
Mmmm, that's a big honking standalone device that is awkward to use in combination with a computer. What really perplexes me about this is that, as described by Bassman59, all I'm asking for is that the software just re-arms the trigger continually. That is but 10 lines of code on the software. Can someone confirm that that is actually, honestly not implemented in the Saleae software, despite the clearly valuable usecases I've contrived? I'm absolutely stunned.
Saleae have had live view on their to do list for a while.
Also note that the Saleae cannot trigger on any data. It can only trigger on edges.
First responder, here, and I guess I could have added more detail.
Yes, you have it right. No the Logic does not have an auto-trigger feature. And even if you scripted something in to "press a button", it wouldn't do anything close to what you are asking.
1. You are manually selecting a number of samples that are collected after each trigger. So it would not repeat/refresh on the next trigger, it would continue to collect data until the manually selected sample size has been reached. Then your scripted button press would finally reset the trigger.
2. Triggering is very basic on this device. It triggers on a preset hi/lo of the number of signals you are monitoring. It doesn't trigger off of sequences. So autotrigger might show you nothing but gibberish, anyway.
3. While the new data is being captured, you will be looking at a white loading screen that is obscuring your last 0.1 Hz "refresh."
4. Each time you capture data, it reverts to a default time base. So you won't be able to "zoom" in/out or scroll left/right to the data you are interested in seeing "refreshed."
The upside to a USB logic analyzer is the # samples is huge. In your example of figuring out which axis is which, you could record for 30 seconds while you fiddle with it. Scrolling through the data, after, to figure out which direction is up. Or, you can hook up your oscope and LA at the same time.
Anyhow, I don't see how you are going to see much on a scope, either. Even if you got a clean triggers, wouldn't you just see randomly changing binary digits, looking like a solid VDD and VSS with a bunch of vertical bars between each bit, on all axes, while you are messing with the accelerometer in the slightest? If your accelerometer has an analog output, yeah, you could see it on a scope. You won't see that on a LA.
When all you want to do is click the arm button, it's time to reach for a macro recorder.
That being said, you're going to have more dead time in a device that loads capture data over USB. Whether that will be responsive enough for what you want I do not know.
Sounds like a mixed signal scope is what you want.
Mmmm, that's a big honking standalone device that is awkward to use in combination with a computer. What really perplexes me about this is that, as described by Bassman59, all I'm asking for is that the software just re-arms the trigger continually. That is but 10 lines of code on the software. Can someone confirm that that is actually, honestly not implemented in the Saleae software, despite the clearly valuable usecases I've contrived? I'm absolutely stunned.
Download the Saleae software and try it in demo mode. You'll immediately discover that it doesn't work the way you hope. You capture by bringing up a capture dialog that waits for an edge trigger, and then it starts capturing bulk data (and lots of it) until you close the dialog. It doesn't work like an oscilloscope. If you want to collect more data, you close the current capture and open a new capture dialog. It's not a live device, but rather like a DAQ.
Fair point, I should have tried downloading and playing with the software first before claiming that it was that easy. Nevertheless, it is self-evident that the hardware is perfectly suited to the vision I described, it's just that the software has a completely different architecture to what I was expecting. And that's frustrating.
I'll also check to see if the SDK allows for the writing of a custom program that just gets presented with a firehose of data (as opposed to an SDK that only allows different post-treatments of data)... if I can script the "live" functionality that I want, I might be happy with that. I.e., if I can tell the API, "I want you to wait for a trigger event, and give me 100ms either side of that trigger event back to me as raw data", then I can just call that function over and over again.
Fair point, I should have tried downloading and playing with the software first before claiming that it was that easy. Nevertheless, it is self-evident that the hardware is perfectly suited to the vision I described, it's just that the software has a completely different architecture to what I was expecting. And that's frustrating.
I'll also check to see if the SDK allows for the writing of a custom program that just gets presented with a firehose of data (as opposed to an SDK that only allows different post-treatments of data)... if I can script the "live" functionality that I want, I might be happy with that. I.e., if I can tell the API, "I want you to wait for a trigger event, and give me 100ms either side of that trigger event back to me as raw data", then I can just call that function over and over again.
I've never used the socket API (just the analyzer API, personally), but there may be code here that can accomplish something similar to what you want:
https://github.com/saleae/SaleaeSocketApiYou may have to do visualization yourself though.
You should download the Intronix LogicPort software and give it a try. It has a demo mode. It does SPI, I2C, RS232, and some others.
http://www.pctestinstruments.com/I think it has what you are looking for - just don't know if the memory depth will meet your needs.
Below is a view of the some of the UI. The first image shows the menu toward the top left of the screen - notice the icons just below Help.
In the second image are three particular icons from the second row of the menu that are below Help. In this second image is a green arrow called Single Acquisition. The green arrow with the box running through it/around it is called Recurring Acquisition. The gray box is called Halt. I think you are looking for the
Recurring Acquisition function. You can let Recurring Acquisition run, hit Halt, turn Recurring Acquisition back on, etc. - and you can also set a bunch of trigger conditions for edges, patterns, and more (including data values) under Setup / Trigger (Setup). Some of this might be more useful for parallel than serial but I'm pretty sure you will see that what Intronix calls Recurring Acquisition is along the lines of what you are describing.
I'm in the market for a USB LA, and I was reading a review on the Saleae Logic Pro 8, and one thing that was mentioned was that it does not have continuous triggering. If this means what I think it means, this absolutely blows my mind. I had been completely taking for granted that I could grab just about any LA on the market, hook it up to my SPI accelerometer dev board (for example), trigger on the CS# line, and watch the waveforms and decoded data change/morph* on screen as I twist and turn the accelerometer, just like I can with my Rigol DS2202 oscilloscope (albeit with insufficient channels). Have I misunderstood, or is that really not a reasonable expectation for any LA?
In general a logic analyser does not show realtime data that and if it does, it will be very slow. To see data change in realtime you need an oscillscope (with or without digital channels). This can be handy to do a quick check to see which bits change and get a feel for the values.
I've never used the socket API (just the analyzer API, personally), but there may be code here that can accomplish something similar to what you want:
https://github.com/saleae/SaleaeSocketApi
Thanks, I had a deeper look at that; and it looks like it would do the trick. However, on balance, I find myself leaning towards a Picoscope 3000 series MSO -- the MSO functionality only costs an addition US$250, and it has proper streaming APIs and protocol decoding etc etc... but it is very expensive. Decisions, decisions...
Thanks again for your input everyone.
Why not get a (used) MSO which works?
Why not get a (used) MSO which works?
Because I think the PC connectivity is important for a logic analyzer (heck, the 24" screen for all those digital signals and a mouse with a scroll wheel blow away a standalone unit immediately, before all of the extra analysis options are considered); because bench space is limited here, and because I have other projects in mind which call for a PC-connected 100MHz 4-channel DAC. Nevertheless, thanks for the suggestion -- it's worth a look, maybe I can find a really cheap "throwaway" MSO that'll tide me over in the mean time.
I would just be pumping out the read values to a serial port, and display on pc. If you just want to see which values are being sent to and from a device. I know it doesnt answer your original question. Is how i debugged my embedded system without owning an oscilloscope at school.
I used to think continuous triggering would be important, but for me its only relevancy is seeing what the current state of a signal is, high, low, or transitioning. The benefit continuous triggering has is when viewing repeating signals. Most of my logic analyzer work has not been repeating signals, or there is no benefit to continuous triggering on the signals even if they were repeating.
I would just be pumping out the read values to a serial port, and display on pc. If you just want to see which values are being sent to and from a device. I know it doesnt answer your original question. Is how i debugged my embedded system without owning an oscilloscope at school.
Yeah, in my current case I'm using an Arduino (first mistake
) and I'm using the USART peripheral in SPI mode to do the SPI in question (the dedicated SPI port is busy doing yet other things*). So I haven't got a UART spare at all!
* Yes, I know about #CS; I have my reasons
I have the Intronix LogicPort and can confirm that Recurring Acquisition will do what you describe here.
I have used it many times, and find it useful for seeing if the data changes etc.
It's not quite as responsive as an oscilloscope, but still useful. Around 10 frames per second I guess.
Well, because most things sold as logic analyzers are are just an USB controllers nowadays. I really dont like the Salllee (impossible to write it down) LAs because they are useless with a 10 dollar hardware and a whiny company
Thankfully I got a real USB LA at work, I choose it, and never regret it. It is made by Techtools. So what it does is real time data compression, so if the data doesnt change it will not use memory. Also the memory is in megabits not kilobits. The speed is reasonable for those probes, you get 200 Mhz on 9 channels, 100 on 18. And you can set voltage levels and trigger for data. They have some FPGA magic in it, without it, your tool is just an USB GPIO extender.
So seriously, as always, dont cheap out, buy a decent tool if you really need it. But chosing that, there will not be a bunch of Arduino people telling you that their LA's colors match with their Macbook.