Favorite Logic Analyzer for Hobby Use
Too_Many_Tools
I am currently considering the Tektronix 1240/1241 series.
What is the opinion of the group?
Any suggestions or advice would be appreciated.
TMT
Richard H.
> I am looking for a good basic logic analyzer for hobby use.
HP 1630G is a nice unit if you don't need to go over ~25MHz IIRC. Make
sure you get the pods and all the leads (and clips, if you can). A set
of new clips alone will cost more than the used unit.
Richard
Keyser Soze
news:2El2f.2443$MN6.363@fed1read04...
The 1630G is a fine logic analyzer but finding the fly leads for the pods
has become quite a challenge.
For the HP line you really should go for a 1650 or later model.
There seems to be a lot of 16500(A/B/C) mainframes available on ebay.
If you are going to buy from an auction make sure that a working analyzer is
shown in the pictures with all the cables and fly leads.
All of the HP 165xxx and later analyzer pods require the fly leads or other
input terminator networks.
mike
> "Richard H." <rh...@no.spam> wrote in message
> news:2El2f.2443$MN6.363@fed1read04...
>
>>Too_Many_Tools wrote:
>>
>>>I am looking for a good basic logic analyzer for hobby use.
>>
>>HP 1630G is a nice unit if you don't need to go over ~25MHz IIRC. Make
>>sure you get the pods and all the leads (and clips, if you can). A set of
>>new clips alone will cost more than the used unit.
>>
>>Richard
>
>
> The 1630G is a fine logic analyzer but finding the fly leads for the pods
> has become quite a challenge.
The logic analyzer you need for your hobby depends on what your hobby is.
Back in the old days, you could hook up a logic analyzer to your TTL and
see what was going on. Today, there's way more going on inside that
chip than is visible on the outside. You can spend a lot on a logic
analyzer and still not be able to learn much about what's going on.
So, disclosing more about your hobby would help.
mike
--
Wanted, Serial cable for Dell Axim X5 PDA.
Return address is VALID but some sites block emails
with links. Delete this sig when replying.
FS 500MHz Tek DSOscilloscope TDS540 Make Offer
Bunch of stuff For Sale and Wanted at the link below.
MAKE THE OBVIOUS CHANGES TO THE LINK
ht<removethis>tp://www.geocities.com/SiliconValley/Monitor/4710/
Noel Henson
The 1630D/G the others mention is good. I have and use a Tek1241. I think
you can get one on Ebay for about $150. The cables and clips seem to be
readily available.
I paid $400 6 for mine 6 years ago. It came with a memory upgrade,
1 9-channel 100MHz card and 1 18-channel 50MHz card.
If you're looking at something smaller and/or mixed-signal, you should
check out the BitScope (www.bitscope.com). There is also one tuned for
BASIC Stamps from Parallax (www.parallax.com). The Saelig company imports
several small, logic analyzers and scopes (www.saelig.com).
HTH,
Noel
joep
they power up quickly (without any floppy boot disk needed) easy to use
and reliable, like others said, make sure they have the test clips,
like this one
Not Really Me
"Too_Many_Tools" <too_man...@yahoo.com> wrote in message
news:1128915881.9...@g43g2000cwa.googlegroups.com...
http://www.tech-tools.com/dv_main.htm
$500 with 18 channels, software runs on a PC via USB. We use it all the
time and it works very well.
--
Scott
Validated Software Corp.
Rich Webb
<too_man...@yahoo.com> wrote:
The LogicPort is probably the best home/hobby deal today. It's small
enough to carry in a laptop bag, has 32 channels + 2 clock, and
reasonable depth as it uses event stamping and not free-running
recording. Connects to a PC via USB without needing an additional power
supply. The software runs in demo mode if it doesn't detect an
instrument so you can take it for something like a test drive.
Best price I've seen is here (where I bought mine)
http://www.circuitspecialists.com/prod.itml/icOid/8251
They'll also throw in a cheap but serviceable DMM as a free promo (see
the info at http://www.circuitspecialists.com/). I've gotten a couple of
them and while they're not Flukes, they're OK meters.
LogicPort homepage at http://www.pctestinstruments.com/
--
Rich Webb Norfolk, VA
John Larkin
I've never used a logic analyzer. Seems to me that in a fraction of
the time it takes to learn how to use one, and set up all the
connections, and acquire and analyze all the data, you could have
solved the problem in the comfort of your office, sipping coffee,
thinking over the logic design like you should have in the first
place.
Logic analysis, like software debugging, usually just points out stuff
that should have been obvious from the beginning. Both contribute to
the hack-and-fiddle style of design.
John
Alex Gibson
"Too_Many_Tools" <too_man...@yahoo.com> wrote in message
news:1128915881.9...@g43g2000cwa.googlegroups.com...
ant8 http://www.rockylogic.com/products/ant8.html
Keith Williams
jjla...@highNOTlandTHIStechnologyPART.com says...
> On Sun, 09 Oct 2005 20:56:57 -0700, "Richard H." <rh...@no.spam> wrote:
>
> >Too_Many_Tools wrote:
> >> I am looking for a good basic logic analyzer for hobby use.
> >
> >HP 1630G is a nice unit if you don't need to go over ~25MHz IIRC. Make
> >sure you get the pods and all the leads (and clips, if you can). A set
> >of new clips alone will cost more than the used unit.
> >
> >Richard
>
>
> I've never used a logic analyzer. Seems to me that in a fraction of
> the time it takes to learn how to use one, and set up all the
> connections, and acquire and analyze all the data, you could have
> solved the problem in the comfort of your office, sipping coffee,
> thinking over the logic design like you should have in the first
> place.
For simple problems, maybe. I take it that you don't approve of emulators or
debuggers either?
> Logic analysis, like software debugging, usually just points out stuff
> that should have been obvious from the beginning. Both contribute to
> the hack-and-fiddle style of design.
I once had a problem that took *weeks* (at >80hrs per) to find. I pretty much
knew what the problem was but couldn't prove it. Management wouldn't get me a
logic analyzer so I had to "hack-and-fiddle" in on the problem with an 8051
emulator, while cycling power on a rather expensive mainframe (a customer's
machine, no less). We ended up putting so many cycles on the system that the
processor had to be replaced ($everal hundred thou$and). A logic analyzer would
have cost maybe $10K, or maybe $1K to rent. Hey, that's what management
wanted.
--
Keith
Phil Hobbs
> Logic analysis, like software debugging, usually just points out stuff
> that should have been obvious from the beginning. Both contribute to
> the hack-and-fiddle style of design.
>
This is true in principle, but only if everyone working on a project is
infinitely smart, and all the APIs, tools, and libraries are bug-free
and are described exactly correctly in the docs. For example, I have a
massively multithreaded, clusterized electromagnetic simulator. It
works great on a single machine (including SMP) but the clusterized
version currently has some race condition in the TCP/IP sockets
communication--it causes data corruption about 1 time in 5000. This is
clearly pilot error, since it does similar but not identical things on
Linux, Windows, and OS/2, with 3 different compilers. Just localizing
where the problem occurs is hard even *with* a debugger.
My communications code is all logic-table driven, with clearly defined
pre- and post-conditions, all resources shared by different threads are
serialized, and so forth. It's nicely modular and object-oriented, so I
can rip the TCP/IP comms code out and cram in local communications
without recompiling most of it. I know roughly where the problem is
occurring. I've gone over the logic N times in the way you suggest.
And I'm still probably going to have to re-code the whole receiver end.
Bugs are like sins--it's possible to avoid each individual one, but not
possible to avoid all of them, every time.
Cheers,
Phil Hobbs
Tim Auton
>On Sun, 09 Oct 2005 20:56:57 -0700, "Richard H." <rh...@no.spam> wrote:
>>Too_Many_Tools wrote:
>>> I am looking for a good basic logic analyzer for hobby use.
>>
>>HP 1630G is a nice unit if you don't need to go over ~25MHz IIRC. Make
>>sure you get the pods and all the leads (and clips, if you can). A set
>>of new clips alone will cost more than the used unit.
>
>the time it takes to learn how to use one, and set up all the
>connections, and acquire and analyze all the data, you could have
>solved the problem in the comfort of your office, sipping coffee,
>thinking over the logic design like you should have in the first
>place.
It's not uncommon for hobbyists to be dealing with 'black boxes' at
some points in the design - sensor modules, rf modules, salvaged
controller boards and the like. Often datasheets aren't available or
don't provide enough information. You can't analyse the logic on paper
if you don't know exactly what it is. For that you need to
characterise your 'black box'. A logic analyser can make this much
easier.
Tim
--
Shares are your votes in a pigologocracy.
Noel Henson
For actual logic errors, I tend to agree with you. But timing and assembly
errors can be very difficult to debug without a logic analyzer. A good
analogy would be a doctor and a patient. The cause of many symptoms cannot
be diagnosed without tests. I find a logic analyzer to be an indespensable
tool during prototyping.
Noel
Grant Edwards
>>> I am looking for a good basic logic analyzer for hobby use.
>
> I've never used a logic analyzer. Seems to me that in a
> fraction of the time it takes to learn how to use one, and set
> up all the connections, and acquire and analyze all the data,
> you could have solved the problem in the comfort of your
> office, sipping coffee, thinking over the logic design like
> you should have in the first place.
Wow.
You can diagnose hardware failures by sipping coffee and
thinking?
You _are_ good.
--
Grant Edwards grante Yow! Yow! I threw up on
at my window!
visi.com
John Larkin
wrote:
>In article <cc0lk1ls1tv4uemli...@4ax.com>,
>jjla...@highNOTlandTHIStechnologyPART.com says...
>> On Sun, 09 Oct 2005 20:56:57 -0700, "Richard H." <rh...@no.spam> wrote:
>>
>> >Too_Many_Tools wrote:
>> >> I am looking for a good basic logic analyzer for hobby use.
>> >
>> >HP 1630G is a nice unit if you don't need to go over ~25MHz IIRC. Make
>> >sure you get the pods and all the leads (and clips, if you can). A set
>> >of new clips alone will cost more than the used unit.
>> >
>> >Richard
>>
>>
>> I've never used a logic analyzer. Seems to me that in a fraction of
>> the time it takes to learn how to use one, and set up all the
>> connections, and acquire and analyze all the data, you could have
>> solved the problem in the comfort of your office, sipping coffee,
>> thinking over the logic design like you should have in the first
>> place.
>
>For simple problems, maybe.
The more complex it it, the more it deserves careful design.
> I take it that you don't approve of emulators or
>debuggers either?
>
I use a background debug pod to test uP code. It plugs into the bdm
header and lets you load/step/modify code. What it usually does is
concentrate your attention on a section of code where you (I) made a
dumb mistake. I always read over my code several times before I run
it, so I find most of the bugs before it's ever run.
Most logic problems, including electrical glitches/crosstalk and such
less-predictable stuff, can be found with an oscilloscope.
A lot of engineers and programmers spend 20% of their time designing
and 80% debugging. That's clearly inefficient and sloppy design, and
they usually declare victory when *most* of the bugs are eliminated.
Fancy analysis tools may be fun to play with, but they encourage
design-by-test instead of design-by-design.
The harder it is to debug, the more careful people are in the initial
design. VLSI chips and moon rockets are examples.
So, what did the 8051 problem turn out to be?
John
John Larkin
wrote:
>On 2005-10-10, John Larkin <jjla...@highNOTlandTHIStechnologyPART.com> wrote:
>
>>>> I am looking for a good basic logic analyzer for hobby use.
>>
>> I've never used a logic analyzer. Seems to me that in a
>> fraction of the time it takes to learn how to use one, and set
>> up all the connections, and acquire and analyze all the data,
>> you could have solved the problem in the comfort of your
>> office, sipping coffee, thinking over the logic design like
>> you should have in the first place.
>
>Wow.
>
>You can diagnose hardware failures by sipping coffee and
>thinking?
>
Hardware failures, as in fried chips, are usually obvious from simple
electrical behavior; a DVM and a scope are usually all you need here,
or just have manufacturing replace the chip if it's in doubt. Why
should I spend days of my time with a logic analyzer testing a suspect
standard chip when I can have it replaced in a half hour?
Beside, admit it: 95% of the time the problem is a dumb design error,
right in front of your face, not a bad part. I *can* find dumb design
errors sipping coffee and thinking.
John
Spehro Pefhany
<gra...@visi.com> wrote:
>On 2005-10-10, John Larkin <jjla...@highNOTlandTHIStechnologyPART.com> wrote:
>
>>>> I am looking for a good basic logic analyzer for hobby use.
>>
>> I've never used a logic analyzer. Seems to me that in a
>> fraction of the time it takes to learn how to use one, and set
>> up all the connections, and acquire and analyze all the data,
>> you could have solved the problem in the comfort of your
>> office, sipping coffee, thinking over the logic design like
>> you should have in the first place.
>
>Wow.
>
>You can diagnose hardware failures by sipping coffee and
>thinking?
>
>You _are_ good.
The thinking part is obligatory, the logic analyzer presumably just
gives you more (and perhaps better) information to work with.
Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
sp...@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Jim Stewart
> "Richard H." <rh...@no.spam> wrote in message
> news:2El2f.2443$MN6.363@fed1read04...
>
>>Too_Many_Tools wrote:
>>
>>>I am looking for a good basic logic analyzer for hobby use.
>>
>>HP 1630G is a nice unit if you don't need to go over ~25MHz IIRC. Make
>>sure you get the pods and all the leads (and clips, if you can). A set of
>>new clips alone will cost more than the used unit.
>>
>>Richard
>
>
> The 1630G is a fine logic analyzer but finding the fly leads for the pods
> has become quite a challenge.
You can make your own by grinding off the locking
ridge from Molex .156" shrouds.
> For the HP line you really should go for a 1650 or later model.
>
> There seems to be a lot of 16500(A/B/C) mainframes available on ebay.
If you have the bench space, a 16500 with scope cards
and a fast analyzer card is a great and cheap tool.
Jim Stewart
You're a better engineer than me.
I don't believe in the hack-and-fiddle style of design
either. On the other hand, about twice a year the
logic analyzer saves my ass and shows me why I've been
banging my head against the wall for a couple of days.
> John
>
Grant Edwards
>>You can diagnose hardware failures by sipping coffee and
>>thinking?
>
> Hardware failures, as in fried chips, are usually obvious from simple
> electrical behavior;
I'm thinking more of things that don't meet their timing specs
or are just plain buggy and don't work the way the data sheet
says.
> Beside, admit it: 95% of the time the problem is a dumb design
> error, right in front of your face, not a bad part. I *can*
> find dumb design errors sipping coffee and thinking.
I agree that looking that the code and thinking about it is
often the best way to find software design problems. but I've
dealt with enough buggy and broken hardware that I wouldn't
want to entirely do without a good 4-channel DSO or a logic
analyzer.
Not to mention trying to reverse engineer something...
--
Grant Edwards grante Yow! Yow!! "Janitor
at trapped in sewer uses ESP
visi.com to find decayed burger"!!
Jim Thompson
wrote:
>On 2005-10-10, John Larkin <jjla...@highNOTlandTHIStechnologyPART.com> wrote:
>
[snip]
>
>> Beside, admit it: 95% of the time the problem is a dumb design
>> error, right in front of your face, not a bad part. I *can*
>> find dumb design errors sipping coffee and thinking.
>
>I agree that looking that the code and thinking about it is
>often the best way to find software design problems. but I've
>dealt with enough buggy and broken hardware that I wouldn't
>want to entirely do without a good 4-channel DSO or a logic
>analyzer.
>
>Not to mention trying to reverse engineer something...
I always find it helpful to have a "disinterested" person take a look.
For some reason designers always overlook their own mistakes ;-)
...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice:(480)460-2350 | |
| E-mail Address at Website Fax:(480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |
I love to cook with wine. Sometimes I even put it in the food.
John Woodgate
wrote (in <11kl3fr...@corp.supernews.com>) about 'Favorite Logic
Analyzer for Hobby Use', on Mon, 10 Oct 2005:
>You can diagnose hardware failures by sipping coffee and thinking?
>
>You _are_ good.
You just think about where the smoke came from. Even if it IS rocket
science.
--
Regards, John Woodgate, OOO - Own Opinions Only.
If everything has been designed, a god designed evolution by natural selection.
http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk
Too_Many_Tools
In your opinion, is it better to buy an older logic analyzer or to get
a new one?
I mentioned the Tektronix 1240/1241 series because I had used one many
years ago and was impressed.
As for using or not using a logic analyzer, more than once I have found
designs to not behave as they should because of race conditions that
were caused by out of spec vendor parts.
Logic analyzers are as important as an oscilloscope in my opinion.
TMT
Paul E. Bennett
>>> I've never used a logic analyzer. Seems to me that in a fraction of
>>> the time it takes to learn how to use one, and set up all the
>>> connections, and acquire and analyze all the data, you could have
>>> solved the problem in the comfort of your office, sipping coffee,
>>> thinking over the logic design like you should have in the first
>>> place.
>>
>>For simple problems, maybe.
>
> The more complex it it, the more it deserves careful design.
I am with John larkin on this one. Careful design, with plenty of
fore-thought, and a decent highly modular structure will tend to lessen the
need for use of a logic analyser. This applies to hardware logic as well as
to microprocessor based logic. Once I am satisfied that my power rails
behave themselves I rarely need even a scope. A simple logic probe coupled
with the ability to have close control over the hardware during the
problematic code segment suffices.
>> I take it that you don't approve of emulators or
>>debuggers either?
[%X]
Emulators, yes. Debuggers (as in a peice of extra equipment) no. That,
though, is just a measure of how closely I can control the hardware with my
Forth based set-up. However, rigorous review of the design should eliminate
the majority of silly mistakes.
> A lot of engineers and programmers spend 20% of their time designing
> and 80% debugging. That's clearly inefficient and sloppy design, and
> they usually declare victory when *most* of the bugs are eliminated.
> Fancy analysis tools may be fun to play with, but they encourage
> design-by-test instead of design-by-design.
They should try switching those proportions around a bit. >70% design, 20%
test and <10% debug.
--
********************************************************************
Paul E. Bennett ....................<email://p...@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************
Keith Williams
jjla...@highNOTlandTHIStechnologyPART.com says...
> On Mon, 10 Oct 2005 11:30:40 -0400, Keith Williams <k...@att.bizzzz>
> wrote:
>
> >In article <cc0lk1ls1tv4uemli...@4ax.com>,
> >jjla...@highNOTlandTHIStechnologyPART.com says...
> >> On Sun, 09 Oct 2005 20:56:57 -0700, "Richard H." <rh...@no.spam> wrote:
> >>
> >> >Too_Many_Tools wrote:
> >> >> I am looking for a good basic logic analyzer for hobby use.
> >> >
> >> >HP 1630G is a nice unit if you don't need to go over ~25MHz IIRC. Make
> >> >sure you get the pods and all the leads (and clips, if you can). A set
> >> >of new clips alone will cost more than the used unit.
> >> >
> >> >Richard
> >>
> >>
> >> I've never used a logic analyzer. Seems to me that in a fraction of
> >> the time it takes to learn how to use one, and set up all the
> >> connections, and acquire and analyze all the data, you could have
> >> solved the problem in the comfort of your office, sipping coffee,
> >> thinking over the logic design like you should have in the first
> >> place.
> >
> >For simple problems, maybe.
>
> The more complex it it, the more it deserves careful design.
Sure, but complex problems, even with careful design tend to produce complex
errors.
> > I take it that you don't approve of emulators or
> >debuggers either?
> >
>
> I use a background debug pod to test uP code. It plugs into the bdm
> header and lets you load/step/modify code. What it usually does is
> concentrate your attention on a section of code where you (I) made a
> dumb mistake. I always read over my code several times before I run
> it, so I find most of the bugs before it's ever run.
Same deal with logic analyzers. The parallel is obvious. ;-)
> Most logic problems, including electrical glitches/crosstalk and such
> less-predictable stuff, can be found with an oscilloscope.
UNless the error only happens once a day. ...or maybe not.
> A lot of engineers and programmers spend 20% of their time designing
> and 80% debugging. That's clearly inefficient and sloppy design, and
> they usually declare victory when *most* of the bugs are eliminated.
> Fancy analysis tools may be fun to play with, but they encourage
> design-by-test instead of design-by-design.
I don't think that follows, any more than emulators do the same for software.
Sloppy is just sloppy.
> The harder it is to debug, the more careful people are in the initial
> design. VLSI chips and moon rockets are examples.
My day job happens to be processor verification. These things are designed
fairly carefully, but simulation is still needed. Simulation tools are quite
analogous to a logic analyzer.
> So, what did the 8051 problem turn out to be?
The application was the hardware for entry, storage, and physical security of
crypto keys. The CPU powered up driving noise (oscillating, actually) over the
interface. Once in a great while the 8051 detected an illegal command sequence
on the interface and ate the keys, as it was designed to do (detected tamper).
The problem would have been easy to track down by stopping a logic analyzer on
a detected error (easy to pick that branch point on the 8051) and look back at
what caused the failure. Without the analyzer I had to track back through the
executed code and infer what happened. Since it took roughly an hour to cycle
the CPU[*] and the fault on the worst system happened perhaps one out of every
20 power cycles, it took time. Every step backtracking took another failing
power cycle.
[*] After we determined that the fault had nothing to do with the 8051
function, the OS, or any programs running on the CPU we found that we could
shorten the time to just a reset, maybe five-ten minutes per cycle. It was
still a lot of waiting around for something to happen.
--
Keith
Lanarcam
John Larkin wrote:
> Logic analysis, like software debugging, usually just points out stuff
> that should have been obvious from the beginning. Both contribute to
> the hack-and-fiddle style of design.
I tend to agree in general, but once in a multitasking application,
events were lost very seldom and nothing was wrong in our code. The
bug was in the RTOS we had bought and we were able to pinpoint the
problem only with the help of an emulator. It happened that the
kernel lost events in rare occasions and this was due to the fact
that interrupts were not disabled at a critical time. Without an
emulator it would have been impossible to find it. The problem was
solved by patching the hexadecimal code.
Keith Williams
thegr...@example.com says...
> On Mon, 10 Oct 2005 16:23:45 -0000, Grant Edwards <gra...@visi.com>
> wrote:
>
> >On 2005-10-10, John Larkin <jjla...@highNOTlandTHIStechnologyPART.com> wrote:
> >
> [snip]
> >
> >> Beside, admit it: 95% of the time the problem is a dumb design
> >> error, right in front of your face, not a bad part. I *can*
> >> find dumb design errors sipping coffee and thinking.
> >
> >I agree that looking that the code and thinking about it is
> >often the best way to find software design problems. but I've
> >dealt with enough buggy and broken hardware that I wouldn't
> >want to entirely do without a good 4-channel DSO or a logic
> >analyzer.
> >
> >Not to mention trying to reverse engineer something...
>
> I always find it helpful to have a "disinterested" person take a look.
> For some reason designers always overlook their own mistakes ;-)
Sure. Same project a year or so earlier; I couldn't wake up the 8051 for
beans. Nothing I did for weeks (other than a reset) worked. I was re-running
my power calculations to see if I could get away without putting it to sleep at
all. I was missing about 50% of the needed power. :-( Anyway, my manager
asked if he could help. I said sure, gave him an hour dissertation on the
problem, gave him a copy of the 8051 databook, and sent him on his way. The
next morning he came in and the conversation went sorta:
Manager: "did you try...?".
Me: "Huh?" "What?" "Why?"
Manager: "It says here on page..."
Me: "Let me see that!" Aw, $#|+! "Wait, that's not what my databook says."
Yep, different versions of the databook with only one paragraph changed. Mine
was the previous year's, with all my notes and dog-ears. Evidently, Intel had
an oops in the interrupt logic, fixed in documentation.
--
Keith
Tim Auton
I think John's point is that if the RTOS was designed properly in the
first place you wouldn't have had that problem. Which is true.
Unfortunately most of us live in the real world; with imperfect
documentation, imperfect devices, imperfect software and imperfect
selves. Eliminating those imperfections is the ideal, but while we're
still trying to get there I think there will still be a healthy market
for logic analysers and software debuggers. Even if the people who buy
them use them only to find the other guy's mistake.
Anthony Fremont
"Phil Hobbs" <pc...@SpamMeSenseless.pergamos.net> wrote in message
news:434A8A35...@SpamMeSenseless.pergamos.net...
I hear you and agree with you. Have you tried explaining the code to
someone else, in detail of course? When I was stuck on something like
this in my past life as a programmer, I would often find the problem by
painfully explaining the workings of the code to a coworker. They
didn't really have to contribute anything useful to the one-sided
conversation, just pretending to listen was often enough. During the
course of explaining it all, the lights would often go on mid sentence.
Dirk Bruere at Neopax
Then you have obviously never worked on a design where a particular chip had an
undocumented 'feature'.
--
Dirk
The Consensus:-
The political party for the new millenium
http://www.theconsensus.org
joep
port PC based logic analyzer, its not easy to make a good logic
analyzer, Tek and Hp have vast engineering experience behind them, and
I wouldn't trust the no name PC based brands, I would always be second
guessing myself (was that really what the circuit was doing or an
artifact of the cheapo analyzer) and I wouldn't want to lug around a PC
to use it.
I would highly recommend that if your familiar with the Tek 1240's and
it fills your current needs then that should be your first choice. I
have much experience with the HP's and I trust what I am seeing, so
that's what I use.
"Logic analyzers are as important as an oscilloscope in my opinion. "
Yes, the logic analyzer hater curiously admitted he never used one,
like a Doctor never using a MRI, guess you don't miss what you never
had
Jim Thompson
<sp...@anywhere.com> wrote:
[snip]
>Have you tried explaining the code to
>someone else, in detail of course? When I was stuck on something like
>this in my past life as a programmer, I would often find the problem by
>painfully explaining the workings of the code to a coworker. They
>didn't really have to contribute anything useful to the one-sided
>conversation, just pretending to listen was often enough. During the
>course of explaining it all, the lights would often go on mid sentence.
Yep, that works, too... awwwwh shit ;-)
Terry Given
Oh, I get it - hobbyists need logic analysers. LOL
Cheers
Terry
Rich Grise
> On Sun, 09 Oct 2005 20:56:57 -0700, "Richard H." <rh...@no.spam> wrote:
>>Too_Many_Tools wrote:
>>> I am looking for a good basic logic analyzer for hobby use.
>>
>>HP 1630G is a nice unit if you don't need to go over ~25MHz IIRC. Make
>>sure you get the pods and all the leads (and clips, if you can). A set
>>of new clips alone will cost more than the used unit.
>>
>
> I've never used a logic analyzer. Seems to me that in a fraction of
> the time it takes to learn how to use one, and set up all the
> connections, and acquire and analyze all the data, you could have
> solved the problem in the comfort of your office, sipping coffee,
> thinking over the logic design like you should have in the first
> place.
>
> that should have been obvious from the beginning. Both contribute to
> the hack-and-fiddle style of design.
>
I once slapped together an 8-channel mux for an ordinary scope input,
to debug somebody _else's_ design. (the guys in R&D were idiots, so
it fell on me and the other two "engineering techs" to fix all of
their crap and write ECOs.)
But a full-on logic analyzer, on a hobbyist budget? I wish I was
rich enough to have a hobby like that! Albeit, if I _did_ have that
kind of budget, I'd probably go skydiving. ;-)
Cheers!
Rich
John Larkin
Really silly sport. You sit around under a tree most of the day
drinking beer and telling lies, and if you're lucky (and rich) get two
15-minute rides up in a crowded plane and two 1-minute jumps down. Oh
yeah, you get to repack your chute for comic relief.
I made two jumps. Second one, I rolled wrong and twisted both my
ankles. Crappy 22-foot military canopies let you down hard! I had to
crawl to the bathroom for two weeks. So now I ski, in nice hard
shin-high plastic boots.
John
>Cheers!
>Rich
>
John Larkin
<pc...@SpamMeSenseless.pergamos.net> wrote:
>John Larkin wrote:
>
>
>> Logic analysis, like software debugging, usually just points out stuff
>> that should have been obvious from the beginning. Both contribute to
>> the hack-and-fiddle style of design.
>>
>
>This is true in principle, but only if everyone working on a project is
>infinitely smart, and all the APIs, tools, and libraries are bug-free
>and are described exactly correctly in the docs.
If you're using somebody else's IP, and especially if you don't have
the (fully commented) source code, then you are indeed in the analysis
business. I understand that some of Microsoft's TCP/IP socket stuff is
*only* documented by the code itself.
That's why I like to program in assembly, bare metal, no RTOS, and do
FPGAs as schematics. It's all there, in plain sight.
>For example, I have a
>massively multithreaded, clusterized electromagnetic simulator. It
>works great on a single machine (including SMP) but the clusterized
>version currently has some race condition in the TCP/IP sockets
>communication--it causes data corruption about 1 time in 5000. This is
>clearly pilot error, since it does similar but not identical things on
>Linux, Windows, and OS/2, with 3 different compilers. Just localizing
>where the problem occurs is hard even *with* a debugger.
What do you do there? Seems like you'd need a multiport comm protocol
analyzer.
But why are you doing this, and not designing optics? Computer systems
stuff is an infinite source (frustration) / sink (time.)
John
Richard H.
> I use a background debug pod to test uP code. It plugs into the bdm
> header and lets you load/step/modify code. What it usually does is
> concentrate your attention on a section of code where you (I) made a
> dumb mistake. I always read over my code several times before I run
> it, so I find most of the bugs before it's ever run.
John,
I agree that more effort should be put into the up-front design.
But if a processor / fpga has built-in debug facilities, you're
effectively already using a logic analyzer (and a more powerful one at
that, often with the ability to halt on instructions and register
values, manipulate registers, etc.)
On low-end processors, these facilities don't exist. They often have
the option of running in a sterile emulator (good for debugging logic
problems), or running at full-speed on the real hardware with no debug
port. That's where the external LA is a very handy tool - especially
when that external controller chip isn't behaving quite as documented.
Richard
Bob Monsen
> On Sun, 09 Oct 2005 20:56:57 -0700, "Richard H." <rh...@no.spam> wrote:
>
>> [quoted text muted]
>
>
> I've never used a logic analyzer. Seems to me that in a fraction of
> the time it takes to learn how to use one, and set up all the
> connections, and acquire and analyze all the data, you could have
> solved the problem in the comfort of your office, sipping coffee,
> thinking over the logic design like you should have in the first
> place.
>
> Logic analysis, like software debugging, usually just points out stuff
> that should have been obvious from the beginning. Both contribute to
> the hack-and-fiddle style of design.
>
> John
http://www.andrews.edu/~aldy/real_programmers.html
and
http://www.extremeprogramming.org
riscy
good for checking logic timing such as SPI bus, CAN bus. It also very
good for analogue signal of all sort.
Careful design and implementation is a key of successful design,
otherwise we end up more time to diagnose circuit failure than
designing it. We limited by resource and failure do tend to occurs.
HP1630 logic analyser is good model.
John Larkin
>John Larkin wrote:
>> I use a background debug pod to test uP code. It plugs into the bdm
>> header and lets you load/step/modify code. What it usually does is
>> concentrate your attention on a section of code where you (I) made a
>> dumb mistake. I always read over my code several times before I run
>> it, so I find most of the bugs before it's ever run.
>
>John,
>
>I agree that more effort should be put into the up-front design.
>
>But if a processor / fpga has built-in debug facilities, you're
>effectively already using a logic analyzer (and a more powerful one at
>that, often with the ability to halt on instructions and register
>values, manipulate registers, etc.)
>
Not to quibble too much, but a debug monitor, BDM, or other means to
single-step code isn't the same as a logic analyzer. A logic analyzer
samples a running system broadside and stores history in a buffer for
analysis; stopping a program and examining its state is a simpler
process, and doesn't require another box and 80 connections to the
target.
>On low-end processors, these facilities don't exist. They often have
>the option of running in a sterile emulator (good for debugging logic
>problems), or running at full-speed on the real hardware with no debug
>port. That's where the external LA is a very handy tool - especially
>when that external controller chip isn't behaving quite as documented.
>
Most simple CPUs can run a debug monitor (well, maybe not train wrecks
like the 8051) which is all you need to test and debug code. I wrote
my own monitors for several CPUs, including the 6800, 6802, and 6803.
Newer embedded CPUs have background debug ports, where you just
connect a simple, cheap BDM pod to a small, few-pin header on the
target board. Again, this isn't a logic analyzer.
My point was that most people, especially hobbyists, don't need a LA
if they do careful design, which they should do anyhow. I've done
hundreds of embedded systems, including designing one CPU with TTL,
and never had to use a logic analyzer. When one of my guys has a nasty
logic problem, we analyze it on a whiteboard, and ususlly find the
problem in a half hour, often less.
True electrical problems can be found with a good oscilloscope.
Later today, I have to persuade a 24-bit serial ADC and a lot of mux
stuff, and a lot of math code, to all play nice together, using a BDM
pod and a dual-channel scope.
John
John Larkin
wrote:
This is parody, and bad parody at that. Real programmers program in
uppercase and include lots of comments.
>and
>
>http://www.extremeprogramming.org
>
It's interesting that the curent state of programming is so bad that
some people think having two people share a keyboard, and discuss
every line of code, is a viable approach to improvement.
John
Guillaume
>>http://www.extremeprogramming.org
>
> It's interesting that the curent state of programming is so bad that
> some people think having two people share a keyboard, and discuss
> every line of code, is a viable approach to improvement.
I agree with that, more or less.
Peer reviewing of your code on a regular basis can be interesting, but
two people working on the same code all the time? Heck!
I have seen a couple ideas in extreme programming that I thought were
interesting, but the rest is, in my opinion, all hype.
Phil Hobbs
> What do you do there? Seems like you'd need a multiport comm protocol
> analyzer.
The best tool is called Ethereal, which is an IP packet sniffer.
It works great on Linux, but Windows doesn't send packets across the
interface if they're addressed to the local host, even if not addressed
to 127.0.0.1, so there's no way to intercept them. Other than that, a
combination of a good debugger and a whole lot of printf() statements.
The good news is that the problem shows up when I loop the program back
on itself, i.e. have one group of xyz cells talk to another group via
the network, even though both are running on the same host. That makes
debugging less painful than if it only happened on a big cluster. My
favourite debugger by far is the one that came with Visualage C++ for
OS/2, which is the main reason why I still bother with OS/2
compatibility. (The other two reasons are sentimentality and cussedness.)
> But why are you doing this, and not designing optics? Computer systems
> stuff is an infinite source (frustration) / sink (time.)
>
That's true, and it wasn't my first choice. The problem is that there
is no EM code available anywhere that can do what I need to do--which is
to design _and_optimize_ those little infrared antenna/metal-oxide
tunnel junction gizmos that I've been trying to build for the last 3 or
4 years. The problem is that all the action happens down inside a
20-angstrom thick layer of nickel oxide, connected to a 1-um long
antenna, connected to a 0.45 x 0.22 x 10-um silicon waveguide. (The
action is a surface plasmon travelling wave going transversely to the
tunnel junction, to minimize the effects of capacitance.) When you work
out how many little boxes that needs, the number is not small, and
neither is the run time. It has to handle metals and large dielectric
contrasts, (e.g. silver on silicon, n=0.1+j10 on n=3.5+j0), so none of
the nice efficient approximate methods work.
Then all of this number crunching has to be wrapped in an optimization
loop, that adjusts the device geometry, load resistance, and so on to
optimize the detection efficiency and modulation depth. (The manual for
the SMP or uniprocessor version of the simulator is at
http://users.bestweb.net/~hobbs/poems/poemsmanual.html if anyone's
interested. I'm trying to get my mgt to let me open-source it, but
without much progress so far.)
The good news is that I have good waveguides, good (optimized) antennas,
and good (100 ohm) junctions all at the same time now, so I'm going to
try to get some real optical data this week. If you hear happy shouting
from the direction of NY tomorrow or the next day, you'll know it's me.
One of the things I love about my job is that I get to do a whole lot of
different things, e.g. in the past couple of weeks I've done optical
design, silicon fab, metal work, circuits, simulator-writing, evaporator
overhaul, and a bunch of theory. One of the things I hate about it is
that the rock doesn't move much unless I push it, and it's a _big_ rock.
Cheers,
Phil Hobbs
Keith Williams
jjla...@highNOTlandTHIStechnologyPART.com says...
> On Mon, 10 Oct 2005 20:55:56 -0700, "Richard H." <rh...@no.spam> wrote:
>
> >John Larkin wrote:
> >> I use a background debug pod to test uP code. It plugs into the bdm
> >> header and lets you load/step/modify code. What it usually does is
> >> concentrate your attention on a section of code where you (I) made a
> >> dumb mistake. I always read over my code several times before I run
> >> it, so I find most of the bugs before it's ever run.
> >
> >John,
> >
> >I agree that more effort should be put into the up-front design.
> >
> >But if a processor / fpga has built-in debug facilities, you're
> >effectively already using a logic analyzer (and a more powerful one at
> >that, often with the ability to halt on instructions and register
> >values, manipulate registers, etc.)
> >
>
> Not to quibble too much, but a debug monitor, BDM, or other means to
> single-step code isn't the same as a logic analyzer. A logic analyzer
> samples a running system broadside and stores history in a buffer for
> analysis; stopping a program and examining its state is a simpler
> process, and doesn't require another box and 80 connections to the
> target.
So your objection is "80 wires"? I usually build in a debug port
to connect a logic analyzer, then depopulate it later. Xilinx also
has some logic analyzer sorts of things that can be dropped into
the FPGA. There are many ways to skin the "80 wires" problem,
though usually not every address/data line is needed.
> >On low-end processors, these facilities don't exist. They often have
> >the option of running in a sterile emulator (good for debugging logic
> >problems), or running at full-speed on the real hardware with no debug
> >port. That's where the external LA is a very handy tool - especially
> >when that external controller chip isn't behaving quite as documented.
> >
>
> Most simple CPUs can run a debug monitor (well, maybe not train wrecks
> like the 8051) which is all you need to test and debug code. I wrote
> my own monitors for several CPUs, including the 6800, 6802, and 6803.
> Newer embedded CPUs have background debug ports, where you just
> connect a simple, cheap BDM pod to a small, few-pin header on the
> target board. Again, this isn't a logic analyzer.
Monitors may be all that's needed (like an oscilloscope may be "all
that's needed"), but using an emulator will increase productivity
10-100x. I can drive screws with a hammer too. Right tools, and
all that... ;-)
> My point was that most people, especially hobbyists, don't need a LA
> if they do careful design, which they should do anyhow. I've done
> hundreds of embedded systems, including designing one CPU with TTL,
> and never had to use a logic analyzer. When one of my guys has a nasty
> logic problem, we analyze it on a whiteboard, and ususlly find the
> problem in a half hour, often less.
>
> True electrical problems can be found with a good oscilloscope.
Not always. Find a 1:1E12 signal integrity error. An analyzer
used to trigger (or as part of) an oscilloscope can be invaluable.
> Later today, I have to persuade a 24-bit serial ADC and a lot of mux
> stuff, and a lot of math code, to all play nice together, using a BDM
> pod and a dual-channel scope.
I've done that sort of thing with no more than a scope (and
emulator) too. Not all problems are as simple.
--
Keith
Rich Grise
> On Mon, 10 Oct 2005 15:51:23 -0000, Grant Edwards <gra...@visi.com> wrote:
>
>>On 2005-10-10, John Larkin <jjla...@highNOTlandTHIStechnologyPART.com>
>>wrote:
>>
>>>>> I am looking for a good basic logic analyzer for hobby use.
>>>
>>> I've never used a logic analyzer. Seems to me that in a fraction of the
>>> time it takes to learn how to use one, and set up all the connections,
>>> and acquire and analyze all the data, you could have solved the problem
>>> in the comfort of your office, sipping coffee, thinking over the logic
>>> design like you should have in the first place.
>>
>>Wow.
>>
>>You can diagnose hardware failures by sipping coffee and thinking?
>>
>>
> Hardware failures, as in fried chips, are usually obvious from simple
> electrical behavior; a DVM and a scope are usually all you need here, or
> just have manufacturing replace the chip if it's in doubt. Why should I
> spend days of my time with a logic analyzer testing a suspect standard
> chip when I can have it replaced in a half hour?
This reminds me of when I was repairing video games - I know, it's not
design, but troubleshooting is troubleshooting. The policy was something
like, "If you're spending more than a half-hour diagnosing the thing,
just shotgun it" i.e., just replace every chip on the board. It was
cheaper than sitting there for four hours figuring out which 7400 was
intermittent. :-)
Our Shop Rate:
$30.00 / hr.
$35.00 / hr. if you watch
$45.00 / hr. if you help
$60.00 / hr. if your kid helps.
Cheers!
Rich
Charlie Edmondson
A number of years ago, I worked for a company doing toll road
electronics. One system they were working on was a vehicle
classification system. It used a number of different sensors to measure
a vehicle as it passed, at road speeds, through a toll point. It was
pure electronic, so speeds exceeding 90 mph were expected.
For this bit of software magic, they had hired an outside company as
contractors. They were in our test lab, working on the code. While
they were not working at the same keyboard, they were constantly
shouting at each other... BUILDING! I HAVE DAEMONS! and other arcane
nonsense. It was apparent they were working on the system, in real
time, and modifying it as they went along, in true hacker paradigm. It
was pretty distracting, as I was quietly building my own little system
(all hardware!) in the corner.
Finally, after about 3 months of this, they finally had code that
worked. The term spaghetti would be applicable and descriptive! My two
co-workers, who had been 'supervising' the development, went to
management and asked for two month to go back in, and from scratch,
re-write the software now that they knew an effective algorithm. Of
course, they were refused, and a few weeks later, released... 8-)
Charlie
Rich Grise
Cheers!
Rich
Rich Grise
Joe Pfeiffer
>
> Beside, admit it: 95% of the time the problem is a dumb design error,
> right in front of your face, not a bad part. I *can* find dumb design
> errors sipping coffee and thinking.
Then you're a whole lot better than I am...
I don't think I've ever had a bug, either hardware or software, that
in retrospect didn't turn out to be a dumb error (as one of my
professors said once when I was calling myself an idiot for using '='
when I meant '==' in a C program, "there's no such thing as a smart
mistake").
But the vast majority have been found a lot faster by making a
prediction of what the state of the system should be, comparing it
with either a debugger (software) or scope (hardware), and using that
to home in on where the mistake was. I could drink a lot of coffee
while staring at a pile of code before I made the same progress.
And I still remember a race condition in a hardware design once that
only manifested itself after the parts had aged several months
(because the right signal had won the race very time until then); I
don't think I *ever* would have found that one without a logic
analyser.
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
skype: jjpfeifferjr
Jonathan Kirwan
><snip>
> $60.00 / hr. if your kid helps.
Cheap at the price.
Jon
Grant Edwards
> I don't think I've ever had a bug, either hardware or software, that
> in retrospect didn't turn out to be a dumb error
Seriously? You've never had to deal with a buggy part???
Just in the past few years, I've had to hunt down and then work
aroudn bugs in an Ethernet controller, two UARTs, an IIC
controller, and two DMA controllers.
--
Grant Edwards grante Yow! I have seen these
at EGG EXTENDERS in my
visi.com Supermarket... I have read
theINSTRUCTIONS...
larwe
> > in retrospect didn't turn out to be a dumb error
>
> Seriously? You've never had to deal with a buggy part???
Look at the OP's signature.
John Woodgate
wrote (in <pan.2005.10.11....@example.net>) about 'Favorite
Logic Analyzer for Hobby Use', on Tue, 11 Oct 2005:
>Our Shop Rate:
> $30.00 / hr.
> $35.00 / hr. if you watch
> $45.00 / hr. if you help
> $60.00 / hr. if your kid helps.
Is there any flexibility with respect to the age and gender of the
'kid'? (;-)
--
Regards, John Woodgate, OOO - Own Opinions Only.
If everything has been designed, a god designed evolution by natural selection.
http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk
Bob Monsen
People were selling AS/400s for a song a few years ago. Not only is it a
great computer if you can afford the power and figure out how to boot it,
but you can use it for low-rent housing if you can't.
---
Regards,
Bob Monsen
The imaginary expression sqrt(-a) and the negative expression -b, have this
resemblance, that either of them occurring as the solution of a problem
indicates some inconsistency or absurdity. As far as real meaning is
concerned, both are imaginary, since 0-a is as inconceivable as sqrt(-a).
- Augustus De Morgan in 1831
Bob Monsen
> On Mon, 10 Oct 2005 21:46:47 -0700, Bob Monsen <rcsu...@comcast.net>
> wrote:
>
>>On Mon, 10 Oct 2005 08:04:23 -0700, John Larkin wrote:
>>
>>> On Sun, 09 Oct 2005 20:56:57 -0700, "Richard H." <rh...@no.spam> wrote:
>>>
>>>> [quoted text muted]
>>>
>>>
>>> I've never used a logic analyzer. Seems to me that in a fraction of
>>> the time it takes to learn how to use one, and set up all the
>>> connections, and acquire and analyze all the data, you could have
>>> solved the problem in the comfort of your office, sipping coffee,
>>> thinking over the logic design like you should have in the first
>>> place.
>>>
>>> Logic analysis, like software debugging, usually just points out stuff
>>> that should have been obvious from the beginning. Both contribute to
>>> the hack-and-fiddle style of design.
>>>
>>> John
>>
>>http://www.andrews.edu/~aldy/real_programmers.html
>>
>
> This is parody, and bad parody at that.
It is dated, and not all that funny, particularly if you like quiche.
>>
>>http://www.extremeprogramming.org
>>
>>
> It's interesting that the curent state of programming is so bad that
> some people think having two people share a keyboard, and discuss every
> line of code, is a viable approach to improvement.
>
The current state of programming has *always* been bad (similarly to the
current state of morals, culture, teenagers, or anything else.) Although
most programmers will deny this, building big systems is more a matter of
luck and brutal management tactics than anything else. Reference the huge
costly failures associated with ATC, luggage handling systems, star wars,
etc to name but a few. Big canceled projects are almost always the victim
of the failures to deliver software, since it is always orders of
magnitude more complex than the hardware it runs on. Successful software
companies often overcome this problem by attrition, funding many projects
that they later cull when things don't go well, hoping that one of the
many actually makes it to the customer. There is always some group who is
pushing the next thing in programming... structured programming,
object-oriented programming, functional programming, declarative
programming, cooperative programming, extreme programming, program proof,
modular programming, just-in-time programming, ... the list goes on. Most
people ignore these folks, and continue to debug the hideous results of
last year's misguided new paradigm.
Too_Many_Tools
some people think having two people share a keyboard, and discuss every
line of code, is a viable approach to improvement. "
Especially when one of those people is your boss. ;<)
Ever had one of "those" bosses?
Many times a "joint programming exercise" is because the quality of the
programmers is such that you need more than one to code.
TMT
Ken Taylor
news:1129088728.7...@g44g2000cwa.googlegroups.com...
Ken
John Larkin
Actually, it makes sense. If one programmer spends 20% of his time
coding and 80% debugging and still leaves behind a heap of expensive
bugs... not an uncommon situation... this may be net productive.
John
Too_Many_Tools
No Ken, I ASSURE you that these concepts are alive and well in EVERY
company I have ever dealt with....and I mean EVERY company.
In reference to the boss "helping" at the keyboard, the best example I
have seen is when the CEO of a major Fortune 500 company spent an
afternoon "helping" the engineering staff work on a project....and the
CEO had NO engineering background.
It was the classical Dilbert moment.
The sad irony is that they had just laid off 30% of the engineering
staff.
Based on that example, I would say they were the lucky ones.
Dilbert's mythical land of Ebonia is in reality a very real place...and
every company has a group of representatives from there. I am sure you
have dealt with them if you have worked on a hardware/software project.
I note that as I follow this discussion, it is not hard to determine
who is in a management role and who are the ones responsible for
actually doing the work. :<)
TMT
Ken Smith
Keith Williams <k...@att.bizzzz> wrote:
[....]
>Monitors may be all that's needed (like an oscilloscope may be "all
>that's needed"), but using an emulator will increase productivity
>10-100x. I can drive screws with a hammer too. Right tools, and
>all that... ;-)
But .. but .. but .. The hammer *IS* the right tool for driving screws.
>Not always. Find a 1:1E12 signal integrity error. An analyzer
>used to trigger (or as part of) an oscilloscope can be invaluable.
I think someone should produce a simple box that allows you to combine
about 10 logic lines and some state-machining into an external trigger for
an oscilloscope. It would be extra nice if it was low enough in cost that
you can buy more than one and had some method to hook them together.
I've had to chase down cases like where changing something in software
makes the ADC get noisier.
--
--
kens...@rahul.net forging knowledge
Keith Williams
too_man...@yahoo.com says...
> LOL...
>
> No Ken, I ASSURE you that these concepts are alive and well in EVERY
> company I have ever dealt with....and I mean EVERY company.
I've never seen such over-the-shoulder development. I've never had
the luxury of twice the staff as was needed either.
> In reference to the boss "helping" at the keyboard, the best example I
> have seen is when the CEO of a major Fortune 500 company spent an
> afternoon "helping" the engineering staff work on a project....and the
> CEO had NO engineering background.
I've worked for a Fortune 10 company for 30+ years and haven't had
too many times when the boss insisted on "helping". They were
usually too busy in meetings to do any harm (other than by
insisting that I go to the meetings).
One time we were working 7-day-weeks on a project in real trouble.
The big PHB called staff meetings every Sunday from noon to 4:00PM.
"as long as you have you people working on Sunday, so will you".
The project manager (I was loaned out to the group) came in and
held scope probes.
> It was the classical Dilbert moment.
>
> The sad irony is that they had just laid off 30% of the engineering
> staff.
And they still had two people per terminal? ;-)
> Based on that example, I would say they were the lucky ones.
>
> Dilbert's mythical land of Ebonia is in reality a very real place...and
> every company has a group of representatives from there. I am sure you
> have dealt with them if you have worked on a hardware/software project.
That's why Dilbert is funny. We can all see ourselves.
> I note that as I follow this discussion, it is not hard to determine
> who is in a management role and who are the ones responsible for
> actually doing the work. :<)
Point of information: I've never been in management.
--
Keith
Keith Williams
says...
> In article <MPG.1db5b883f...@news.individual.net>,
> Keith Williams <k...@att.bizzzz> wrote:
> [....]
> >Monitors may be all that's needed (like an oscilloscope may be "all
> >that's needed"), but using an emulator will increase productivity
> >10-100x. I can drive screws with a hammer too. Right tools, and
> >all that... ;-)
>
> But .. but .. but .. The hammer *IS* the right tool for driving screws.
;-)
> >Not always. Find a 1:1E12 signal integrity error. An analyzer
> >used to trigger (or as part of) an oscilloscope can be invaluable.
>
> I think someone should produce a simple box that allows you to combine
> about 10 logic lines and some state-machining into an external trigger for
> an oscilloscope. It would be extra nice if it was low enough in cost that
> you can buy more than one and had some method to hook them together.
I wish such a thing were built into the trigger circuitry of a
scope. It would make things a bunch simpler (delayed trigger and
such).
> I've had to chase down cases like where changing something in software
> makes the ADC get noisier.
I've seen such problems mostly with communications between
subsystems. Same difference, I guess.
--
Keith
Dave Hansen
[...]
>It's interesting that the curent state of programming is so bad that
>some people think having two people share a keyboard, and discuss
>every line of code, is a viable approach to improvement.
I've seen a couple guys "pair programming" some hairy image processing
routines. They seemed to do pretty well at it. It helped that they
were both quite good programmers, respected each other, and got along
well. And it was a matter of "try this, and see if it's faster,"
"Nope, that causes problems with denormals here," etc. It wasn't a
system design, rather, it was optimization of some algorithms.
The only "pair programming" I've done was with me at the keyboard and
the hardware engineer at my elbow. I was debugging code, and he was
debugging his new board. Actually, I was just running Forth code to
test his hardware for bring-up. Several situations like that. I
can't imagine trying to "pair program" the kind of code I write would
be very productive.
Regards,
-=Dave
--
Change is inevitable, progress is not.
John Larkin
wrote:
One story I heard was about Burroughs. All their computers were
programmed in Algol, including the Algol compiler. So the wrote the
compiler in Algol and had two guys, working side-by-side, hand-walk it
through itself, on paper, to compile the first bootstrap.
John
J. Clarke
Couple of tales, one from Fortune 500, the other from small business.
Fortune 500, one of my first assignment was to fix a particular problem with
an aircraft component. After doing my initial research I found that there
were applicable specifications aimed directly at avoiding the problem we
were seeing and recommended that we redesign the damned thing _to_ _spec_.
Having met tremendous resistance to this, I started going through the
history. Found a set of drawings, finally, that had had the design to
spec, and found that it had been altered to the current flawed and out of
spec design. And who had signed off on the change? The guy who was now
the VP for engineering.
Small biz, we had a CEO who felt that we should learn from our customers,
which is a good thing in principle. He however felt that the way to learn
was to wander around the customer's office and look at what was on peoples'
desks and whatnot--he got to the point of threatening disciplinary action
if we didn't come back with reports of what we had observed. The customers
had names like "Sandia National Laboratory" and "Lockheed Advanced
Development Projects Office" (aka "Skunk Works"). Finally he decided to
show us how it was done at Boeing Missiles and Space and had a close
encounter of the worst kind with the NSA which mellowed him out
considerably.
--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)
Dave Hansen
<too_man...@yahoo.com> wrote:
[...]
>In reference to the boss "helping" at the keyboard, the best example I
>have seen is when the CEO of a major Fortune 500 company spent an
>afternoon "helping" the engineering staff work on a project....and the
>CEO had NO engineering background.
Possibly worse is a high-level executive _with_ an engineering
background. They tend to sacrifice good engineering practice in the
name of getting it done. IME, it's best to avoid small companies that
have an executive with a title like CTO -- invariably, he or she
"knows" your job "better" than you do, and if you're too lazy or
stupid to "make it happen," he or she will fill in for you until they
can hire someone better.
Perhaps the best (worst?) was a CEO who was a former programmer. When
we told him a certain project would take several months, he got all
disgusted and said something like "I'm no dummy, you can't pull the
wool over my eyes. I can come in this weekend and get this done
before Monday. I've done this kind of thing a hundred times before,"
yada yada yada. The project never did get done...
Jim Stewart
I heard rumors that in the 80's, Bill Gates
would threaten to complete slow/stalled projects
in Quickbasic over the weekend.
Lanarcam
What is really astonishing is that IMHO they believe they can
do it. It tells something about the capacity of the human
brain to become blind to reality. This should never be
underestimated;)
John Woodgate
wrote (in <1129141535....@g43g2000cwa.googlegroups.com>) about
'Favorite Logic Analyzer for Hobby Use', on Wed, 12 Oct 2005:
>What is really astonishing is that IMHO they believe they can do it. It
>tells something about the capacity of the human brain to become blind
>to reality. This should never be underestimated;)
What makes you REALLY spit is to find one who CAN do it. It happened to
a cow-orker. The Great Panjandrum came round about 5 PM and asked about
the hold-up on the project. He came back at 10 AM the following day with
the solution, or, perhaps, A solution. One extra resistor!
Of course, he had time to cheat, by asking someone else in another
division to solve it, but....
Too_Many_Tools
"I think someone should produce a simple box that allows you to combine
about 10 logic lines and some state-machining into an external trigger
for
an oscilloscope. It would be extra nice if it was low enough in cost
that
you can buy more than one and had some method to hook them together. "
Then who would buy logic analyzers? ;<)
Mark Moulding
Always. The more time and effort spent here, the less (at generally several
times the cost) in debug.
> Not to quibble too much, but a debug monitor, BDM, or other means to
> single-step code isn't the same as a logic analyzer. A logic analyzer
> samples a running system broadside and stores history in a buffer for
> analysis; stopping a program and examining its state is a simpler
> process, and doesn't require another box and 80 connections to the
> target.
True. However, not always are there 80 parallel connections. Sometimes a
logic analyzer is handy just for tracking CLK, CS, DI and DO...
> Most simple CPUs can run a debug monitor (well, maybe not train wrecks
> like the 8051) which is all you need to test and debug code. I wrote
A train wreck, perhaps, but an astonishingly widely used one...
> My point was that most people, especially hobbyists, don't need a LA
> if they do careful design, which they should do anyhow. I've done
> hundreds of embedded systems, including designing one CPU with TTL,
> and never had to use a logic analyzer. When one of my guys has a nasty
> logic problem, we analyze it on a whiteboard, and ususlly find the
> problem in a half hour, often less.
Sometimes, no amount of careful design can avoid implementation problems,
especially when the available documentation is poor. I once spent several
days trying to understand why an Oki codec wouldn't produce valid data at
some of the bit rates the data sheet claimed it would. With a logic
analyzer, I was able to figure out why - JapGlish documentation (translation
problems).
> True electrical problems can be found with a good oscilloscope.
More and more, I'm finding that a mixed-signal 'scope is a pretty handy
tool. I'm using the digital trigger condition features of my scope fairly
frequently now; I still use the ancient Tek 475 a lot though, too.
--
Mark
"I prefer heaven for climate, hell for company."
keith
I've done that, but was the hardware type. I've even doen it where I did
the hardware and embedded firmware and another engineer built the test
fixtures and software. These are hardly cases of two cooks in the same
stock though.
--
Keith
Mark Moulding
>> about 10 logic lines and some state-machining into an external trigger
>> for
>> an oscilloscope. It would be extra nice if it was low enough in cost
>> that
>> you can buy more than one and had some method to hook them together.
>
> I wish such a thing were built into the trigger circuitry of a
> scope. It would make things a bunch simpler (delayed trigger and
> such).
I've got an old HP 54201D scope that is exactly as you wished for. Got it
at a swap meet for $50, replaced one resistor in an input channel, and now
it's my primary scope. 300 MHz bandwidth, dual trace, all the usual digital
trace capture/analysis stuff, and a 27-bit logic analyzer-style trigger
section, including missing- and extra-bit detection. Most of the time I use
it as a normal scope, but once in a while, that trigger section is *really*
handy!
Ted
called it "only having one Sun 3/60".
TW
Alex Gibson
"Alex Gibson" <ne...@alxx.net> wrote in message
news:3qvfd2F...@individual.net...> news:1128915881.9...@g43g2000cwa.googlegroups.com...
>>I am looking for a good basic logic analyzer for hobby use.
>>
>> I am currently considering the Tektronix 1240/1241 series.
>>
>> What is the opinion of the group?
>>
>> Any suggestions or advice would be appreciated.
>>
>> TMT
>>
>
> ant8 http://www.rockylogic.com/
>
forgot to say I've been using it for a couple years.
Work great with pics ,avrs cplds etc.
Same size as a usb to serial adaptor cable.
Works fine up 50 - 70 MHz
Uses an ftdichip + a fpga.
Both their products are not galvanically isolated.
But neither are most of the cheap ones.
Great for very quick testing and if you need to get in and test in a tight
location
or on site.
They were talking about releasing the api for others to use and write non
windows software with
I don't know if they have done this yet.
Alex