Hi All...
Well my Saleae Logic 16 has arrived! What a nice piece of hardware! if only I could get it to work :-(
How do you guys hook your logic analyzers up? I have an I2C device on my board. I put some jumper wires (the kind normally used with breadboards) into the header positions for SCK, SCL (analog 4 and 5) and GND and hooked them up the the analyzer. Started the analyzer sampling, started a sketch that moved some I2C data and.... Nothing :-(
Is there a trick to this?
I don't have the 16 but the original Logic. I often use the same male/male breadboard jumper wires to connect the analyzer to the Arduino.
When you say "Nothing" do you mean it samples and you see nothing but solid high or low or does not never sample? Are you using any triggers?
If you don't use any triggers, it may fill its buffers before anything happens or you may need to zoom way out to see the transitions.
Doesn't i2c need the pullups to work? Try something other than i2c, maybe look at the serial port lines and send some data. It's kind of cool to see the wave forms and the serial decode.
--- bill
Well I figured out what I did. I The Logic 16 has two 8 port connectors. I plugged the connector into the one ont eh right, which is channels 9 through 16. I was looking for data on channels 1 and 2. Silly me.
Now I just get even pulses.
I2C does need pullups, on the bus. The board has those. So I think i should be seeing valid data. Maybe the wires are too long or something. I can try SPI and see what happens.
If the LA triggers you will see something. As I2C idles high do you have a falling edge trigger set?
Rob
Graynomad: If the LA triggers you will see something. As I2C idles high do you have a falling edge trigger set?
Ah, that was the problem! As soon as i set the falling trigger I get data. Thanks Rob!
Good, an LA is by far the most useful tool for this type of work IMO. They should be compulsory :)
Rob
Graynomad: Good, an LA is by far the most useful tool for type of work IMO. They should be compulsory :)
Now I need to learn more about the I2C protocol. Its handy being able to tap on to the I2C and/or SPI bus via the Arduino headers. I wish I had access to a nice o scope, it would be cool to see how square the signals are on this board.
I looked at the bit scope, thinking at first for the $300 cost of the Logic 16 that the bit scope, with two analog inputs, was a better idea. But then you add the cost of a half way descent probe and a few other things that were needed, and I decided just to get the logic analyzer.
So then I looked at Logic vs Logic 16. The 16 is twice the price! But once you look into it, its much, much more than twice the analyzer. The software is the same and that's a good thing. The hardware, however, is better than just 8 more channels. The Logic 16 not only adds 8 channels, but they are protected, they can read from a very low voltage up to 5 volts. The data t the PC is buffered, so sampling at high rates can be done with a busy PC without missing data. And, it can sample at a much higher rate than the 8 channel version. The case is a work of art, black aluminum. The bottom has a rubbery base that keeps it from sliding around. The probes seem good quality and you get 16 of them, plus two 8-wire harnesses, plus the USB cable all in a very nice case.
I really had to convince myself to part with the extra $150 above the Logic, but after watching a few reviews on YouTube, I did it, although still begrudgingly. Now that it's here, I'm glad I did.
I'll do a full review after I learn a bit more about how to use it. Over the next few weeks I need to write some I2C code. I already took a crack at it, and quickly realized that without being able to see what's on the bus, I'm not going to get far. So now I have no excuse!
without being able to see what's on the bus, I'm not going to get far.
People develop whole protocols without an LA, buggered if I know how as it's the difference between knowing what's happening and guessing what's happening.
A scope is good as well, those waveforms aren't as nice in the real world as they look on an LA screen :) But in general things work at the physical hardware level these days, it's getting the data flow and higher-level timing right that's the issue.
I'll do a full review after I learn a bit more
Look forward to it.
Rob
skyjumper: Hi All...
Well my Saleae Logic 16 has arrived! What a nice piece of hardware! if only I could get it to work :-(
How do you guys hook your logic analyzers up? I have an I2C device on my board. I put some jumper wires (the kind normally used with breadboards) into the header positions for SCK, SCL (analog 4 and 5) and GND and hooked them up the the analyzer. Started the analyzer sampling, started a sketch that moved some I2C data and.... Nothing :-(
Is there a trick to this?
I too bought a Logic 16, it's a nice little analyzer.
The software could use more T markers, as well as bookmarks. There isn't supposed to be an update until mid year. The triggering options are a bit confusing, but Salea said they were planning on addressing that too.
It really is not that good a value. $300 for 16 channels at 12.5Mhz
when you can get 34 at 500 mhz for 80 bucks more http://www.pctestinstruments.com/
If it was $100 then fine it would be a good solid product, but to be honest it's not even going to keep up with an arduino because you will need to sample at least at two times the clock rate, giving you a max of 4-8 channels.
That Logicport is a real nice gadget but I think it's a little "old school", by that I mean that fast and wide with limited sample memory was how we used to have LAs when we had to debug fast timing issues.
For most people these days that is no longer the case, all the fast stuff is inside the chip, we're looking at port bit flipping and serial busses so I doubt there are many instances of having to sample at 2x the Ardiuno's 16Mhz.
That said I found that using very fast assembly language pulses for debugging can defeat the Saleae at times. OTOH being able to see short bursts of high-speed data occurring over 1sec apart is great.
The Logicport only has a 2048 deep buffer, I note that they have compression, do you know how long a sample it can take?
If I had the money I'd be be inclined to buy both, but as I seldom deal with fast logic these days the Saleae does the job. That may change with the new Due should we ever see them.
Rob
Graynomad: If I had the money I'd be be inclined to buy both, but as I seldom deal with fast logic these days the Saleae does the job. That may change with the new Due should we ever see them.
Rob
The Maple and Chipkit are real today; no need to wait on Due. I have a Chipkit Uno32 and for some of the stuff I'm doing, the Saleae Logic (not Logic 16) is simply not fast enough. Like using pin strobes/pulses for software profiling. They are simply too fast/short to see on the Logic without adding in s/w delays.
But in general I agree that for most things I'm doing right now, it works just fine.
--- bill
bperrybap:
the Saleae Logic (not Logic 16) is simply not fast enough. Like using pin strobes/pulses for software profiling. They are simply too fast/short to see on the Logic without adding in s/w delays. But in general I agree that for most things I'm doing right now, it works just fine. --- bill [/quote]
I've used direct port writes on a 16Mhz Uno to trigger my Logic 16. It works fine. I'm only using 2-3 channels on the Logic 16. The less channels that are used, the higher the sampling rate (within limits).
cappy2112:
bperrybap:
the Saleae Logic (not Logic 16) is simply not fast enough. Like using pin strobes/pulses for software profiling. They are simply too fast/short to see on the Logic without adding in s/w delays. But in general I agree that for most things I'm doing right now, it works just fine. --- bill
I've used direct port writes on a 16Mhz Uno to trigger my Logic 16. It works fine. I'm only using 2-3 channels on the Logic 16. The less channels that are used, the higher the sampling rate (within limits).
Its not the AVR at 16Mhz that is the issue. It is the 80mz pic32 that can be too fast for the Logic sampling rates.
The ability to reuse the bandwidth of unused channels on the Logic 16 is great. That gets quite a bit higher sampling rate when the number of channels is lower than on the original Logic. Theoretically up to 100Mhz if only using two channels.
The part that I believe is very misleading is:
Logic16 can save as many as 10B samples, letting you capture even the most elusive events. No more dealing with frustratingly small sample buffers
To me there needs to be a big and better distinction between "sample buffers" in the device which temporarily protects you against USB speed and latency issues, and the size of the trace that can be stored on the PC. The Logic 16 is not saving 10B samples, it is Logic 16 application s/w running on the PC that can save up to 10B samples that it gets from the Logic 16 via USB.
When streaming the sample data over USB, USB2 is simply not fast enough to support high speed sampling on very many channels. USB3 would be better.
What I'd like to see is allowing the Logic/Logic16 to run in either streaming mode, like it works today, or in "snapshot" mode which is more like a traditional analyzer which would allow much faster captures but for a much shorter amount of time as limited by the internal buffer.
For some uses, even the existing limited buffers inside the Logic/Logic16 would be enough to get pictures of special events, when used with multiple triggers.
--- bill
That seems like a nice analyzer, but I was not about to spend $400. Its bad enough I spent $300! Part of my thinking was that I'm not likely to use 16 channels, or even 8 channels. Mostly, I wanted to see what was happening when I write code for I2C and SPI, since its hard to debug code without knowing what its doing. So two or three channels, maybe 4, is what I need.
My other thinking was that I'll probably need a nice O scope some day, and if it comes to very high speed stuff, I'll use the O scope. But they are pricy, so it can wait.
I had not thought of using it for speed profiling, that's a great idea. One thing I was trying to figure out how to do was to see how quickly my code running on my board (a 16MHz 1284P based board) can respond to an and interrupt and close files on the SD card when power goes away. Now I realize I can throw a pin high when power goes away, another when I enter the ISR and another when the files are closed. This should be fun!
skyjumper:
I had not thought of using it for speed profiling, that’s a great idea. One thing I was trying to figure out how to do was to see how quickly my code running on my board (a 16MHz 1284P based board) can respond to an and interrupt and close files on the SD card when power goes away. Now I realize I can throw a pin high when power goes away, another when I enter the ISR and another when the files are closed. This should be fun!
I used the Logic analyzer to profile my ISR response & latency time.
I was seeing 3-4 uS before the ISR got called, and ~6uS inside the ISR.
Oddly enough, getting back from the ISR to loop() took a horrible amount of time. I never understood why.
There were some posts about the ISR not clearing the interrupt flag. I tried clearing it in the ISR, but didn’t reach any reasonable conclusions.
I’m starting to think it may be better to bite the bullet and ditch the Arduino safety net.
At the same time I’m not looking forward to bringing up a microcontroller from scratch.
Graynomad: For most people these days that is no longer the case, all the fast stuff is inside the chip, we're looking at port bit flipping and serial busses so I doubt there are many instances of having to sample at 2x the Ardiuno's 16Mhz.
It is simply a requirement for sampling digital logic that you sample at at least 2* the speed of the levels you are looking at. So even at 16Mhz you can change the outputs every 62ns. On my recent project for reading a Nand-flash chip on a mega, I would have been sunk if I did not have the width & speed of the Logicport.
The Logicport only has a 2048 deep buffer, I note that they have compression, do you know how long a sample it can take?
Thats what triggers are for.....,but you will notice that most 'cheap' high speed logic analyzers are the same, simply because to use external memory would require memory cycle speeds in the pico second range and that is what you pay for in the really high end HP market. They claim that the compression is 2^33 to 1 at 200Mhz, above that then I guess the FPGA has not got enough time between samples to get it compressed.(It may be that if they had a really good VHDL programmer they could get an improvement)
Now I realize I can throw a pin high when power goes away, another when I enter the ISR and another when the files are closed.
That's how most people do it AFAIK. If you have the spare pins it's a non-intrusive way to debug.
I use a couple of macros
#ifdef CLIENT_ATmega328
#define PULSE0_PIN 8
#define PULSE1_PIN 9
#define PULSE0 asm("sbi 5,0\nnop\nnop\nnop\nnop\ncbi 5,0"); // PORTB bit 0, 328 Arduino D8
#define PULSE1 asm("sbi 5,1\nnop\nnop\nnop\nnop\ncbi 5,1"); // PORTB bit 1, 328 Arduino D9
#endif
#ifdef CLIENT_ATmega2560
#define PULSE0_PIN 10
#define PULSE1_PIN 11
#define PULSE0 asm("sbi 5,4\nnop\nnop\nnop\nnop\ncbi 5,4"); // PORTB bit 4, 2560 Arduino D10
#define PULSE1 asm("sbi 5,5\nnop\nnop\nnop\nnop\ncbi 5,5"); // PORTB bit 5, 2560 Arduino D11
#endif
Note the nops? They are there to widen the pulse because the Saleae isn't quite fast enough. I don't think I needed so many though, can't remember now.
This gets worse with faster chips as has been stated, so because this is such a useful technique I've added dedicated hardware to do this on my new Due design.
Rob
cappy2112: I used the Logic analyzer to profile my ISR response & latency time.
I was seeing 3-4 MS before the ISR got called, and ~6uS inside the ISR. Oddly enough, getting back from the ISR to loop() took a horrible amount of time. I never understood why. There were some posts about the ISR not clearing the interrupt flag. I tried clearing it in the ISR, but didn't reach any reasonable conclusions.
I'm starting to think it may be better to bite the bullet and ditch the Arduino safety net. At the same time I'm not looking forward to bringing up a microcontroller from scratch.
Thanks for posting those numbers, that's very helpful.
I long ago decided that the "Arduino safetynet" was in the way. I'm bit by bit coding past it. Problem is, there are just sooooo many really handy libraries I'm using.
skyjumper: I had not thought of using it for speed profiling, that's a great idea. One thing I was trying to figure out how to do was to see how quickly my code running on my board (a 16MHz 1284P based board) can respond to an and interrupt and close files on the SD card when power goes away. Now I realize I can throw a pin high when power goes away, another when I enter the ISR and another when the files are closed. This should be fun!
Believe it or not, this is mostly what I've used a logic analyzer for during the past 25 years. I've used many different pulse techniques, like a single pulse to enter a code block and a double pulse to exit a code block. This works pretty good even on Logic with up to 8 profiling points.
I've also used 1 pin as marker strobe and then other pins to indicate a code. For example, years and years ago I used to use a Parallel port for this. The strobing code sets a code in 8 bits, then pulses the strobe. On the analyzer you looked at the strobe to see your events, then looked at the 8 bit data to get a code number to see which event it was. This gave up to 256 events that could be traced. You can do the same on the AVR using multiple pins.
The beauty about using hardware strobes for profiling is that they add very little overhead. (well if you avoid things like digitalWrite() to control the pins)
--- bill