General > General Technical Chat

Does a hobbyist need a Oscilloscope?

<< < (12/17) > >>

janoc:

--- Quote from: tggzzz on June 26, 2016, 04:28:59 pm ---
--- Quote from: onesixright on June 26, 2016, 07:41:27 am ---For looking at serial data ( and be able to decode it) you could also consider something like bus pirate (30$).

--- End quote ---

Provided that can dump all the decoded information to a host computer's file, that is probably better than an LA.

--- End quote ---

Err no. Buspirate can act as a sorta logic analyzer in a pinch, but you have 4 (or maybe only 3) channels at best and it is slow, because it is the onboard PIC doing all the work. It is not really designed for that role, it is primarily serial protocol testing tool. Any cheap Saelae Logic clone that sells for $10 on eBay will be running circles around a Buspirate when used as a logic analyzer - those have 24MHz sampling rate and 8 channels.

tggzzz:

--- Quote from: janoc on June 30, 2016, 04:10:55 pm ---
--- Quote from: tggzzz on June 26, 2016, 04:28:59 pm ---
--- Quote from: onesixright on June 26, 2016, 07:41:27 am ---For looking at serial data ( and be able to decode it) you could also consider something like bus pirate (30$).

--- End quote ---

Provided that can dump all the decoded information to a host computer's file, that is probably better than an LA.

--- End quote ---

Err no. Buspirate can act as a sorta logic analyzer in a pinch, but you have 4 (or maybe only 3) channels at best and it is slow, because it is the onboard PIC doing all the work. It is not really designed for that role, it is primarily serial protocol testing tool. Any cheap Saelae Logic clone that sells for $10 on eBay will be running circles around a Buspirate when used as a logic analyzer - those have 24MHz sampling rate and 8 channels.

--- End quote ---

I haven't used either in that role, since my design and implementation strategies have circumvented any such requirement. The systems I've worked with over the decades have typically had series of messages that arrive occasionally and unpredictably.

How would that work with an asynchronous sampling clock and limited depth memory?
Would the capture depth be sufficient?
Would there be any "dead time" between capturing-dumping and restarting the capture?
Would you see the messages as they occurred?
Would you be able to capture and then analyse the sequences of messages off-line?

OTOH, sniffing characters as they go past and copying them to a computer's console and file is remarkably effective.

suicidaleggroll:

--- Quote from: tggzzz on June 30, 2016, 04:29:43 pm ---Provided that can dump all the decoded information to a host computer's file, that is probably better than an LA.

--- End quote ---

That IS a LA...what are you referring to when you say "LA" if it can't decode a huge batch of data and export it to a file?


--- Quote from: tggzzz on June 30, 2016, 04:29:43 pm ---I haven't used either in that role, since my design and implementation strategies have circumvented any such requirement. The systems I've worked with over the decades have typically had series of messages that arrive occasionally and unpredictably.

How would that work with an asynchronous sampling clock and limited depth memory?
With Saleae the data is compressed, so it only takes up space on level transitions, which means sporadic high speed data is no problem.
Would the capture depth be sufficient?
depends on your definition of "enough".  Capturing minutes/hours/days of data at several tens of MHz (or seconds/minutes at several hundred MHz) has always been enough for me
Would there be any "dead time" between capturing-dumping and restarting the capture?
With Saleae, yes, can't speak for others
Would you see the messages as they occurred?
With Saleae, no
Would you be able to capture and then analyse the sequences of messages off-line?
With Saleae, yes
OTOH, sniffing characters as they go past and copying them to a computer's console and file is remarkably effective.
Only if you're dealing with low speed unidirectional async serial.  Throw a couple of SPI, I2C, or parallel busses in the mix and that method of debugging comes crashing down in a big ball of insufficiency.

--- End quote ---

tggzzz:

--- Quote from: suicidaleggroll on June 30, 2016, 04:44:32 pm ---
--- Quote from: tggzzz on June 30, 2016, 04:29:43 pm ---Provided that can dump all the decoded information to a host computer's file, that is probably better than an LA.

--- End quote ---

That IS a LA...what are you referring to when you say "LA" if it can't decode a huge batch of data and export it to a file?

--- End quote ---

There are many devices with many characteristics that have been called an "LA". I don't think it would be profitable to split hairs about what an LA "really" is.


--- Quote ---
--- Quote from: tggzzz on June 30, 2016, 04:29:43 pm ---I haven't used either in that role, since my design and implementation strategies have circumvented any such requirement. The systems I've worked with over the decades have typically had series of messages that arrive occasionally and unpredictably.

How would that work with an asynchronous sampling clock and limited depth memory?
With Saleae the data is compressed, so it only takes up space on level transitions, which means sporadic high speed data is no problem.

--- End quote ---

--- End quote ---

Sounds like compression wouldn't work with something involving a CLK, CE, DATA. The very cheap LAs I looked at didn't have a separate CLK input (or it was improperly terminated); instead they relied on asynchronously sampling to infer the DUT's clock.


--- Quote ---Would the capture depth be sufficient?
depends on your definition of "enough".  Capturing minutes/hours/days of data at several tens of MHz (or seconds/minutes at several hundred MHz) has always been enough for me
Would there be any "dead time" between capturing-dumping and restarting the capture?
With Saleae, yes, can't speak for others

--- End quote ---

OK, so stuff can be missed in an operating system; hit-and-miss for logging and post-mortem dumps.


--- Quote ---Would you see the messages as they occurred?
With Saleae, no

--- End quote ---

So, fine for logging and post-mortem dumps (ignoring the downtime), but not good for interactive debugging or monitoring.


--- Quote ---Would you be able to capture and then analyse the sequences of messages off-line?
With Saleae, yes
OTOH, sniffing characters as they go past and copying them to a computer's console and file is remarkably effective.
Only if you're dealing with low speed unidirectional async serial.  Throw a couple of SPI, I2C, or parallel busses in the mix and that method of debugging comes crashing down in a big ball of insufficiency.

--- End quote ---

All tools and techniques have their limitations. The extent of those limitations depends on the tools and the system being tested.

janoc:

--- Quote from: tggzzz on June 30, 2016, 04:29:43 pm ---I haven't used either in that role, since my design and implementation strategies have circumvented any such requirement. The systems I've worked with over the decades have typically had series of messages that arrive occasionally and unpredictably.

How would that work with an asynchronous sampling clock and limited depth memory?
Would the capture depth be sufficient?
Would there be any "dead time" between capturing-dumping and restarting the capture?
Would you see the messages as they occurred?
Would you be able to capture and then analyse the sequences of messages off-line?

OTOH, sniffing characters as they go past and copying them to a computer's console and file is remarkably effective.

--- End quote ---

I think this is not the thread to argue about what is and isn't an LA. If Buspirate works for your needs (which seem fairly specific and not typical use cases for a logic analyzer, more a serial terminal, btw!), by all means, do keep using it. That's not the point. However, if someone is looking for an LA, Buspirate isn't the best first choice because that function is at best an afterthought in the design of that (otherwise very useful) tool.

I have both a Buspirate, two cheap logic analyzers (a cheap Saleae clone and the OpenBench Logic sniffer) and my scope can do some limited decoding as well, but I would never consider that these tools are somehow interchangeable. Each is good for one thing and sucks big time for another.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod