25 May
2011
25 May
'11
9:50 a.m.
You know, it all depends on the person. Personally, I call the logic
analyzer the "tool of last resort" or "the dreaded logic analyzer".
When
you need it, you need it and nothing else will do. But often you can get a
long way with a 'scope and a logic probe (in the ancient days when strobes
were easily accessible).
When you're debugging a 32 bit bus and you've got probes hanging all over
the place, then you know you are deep in hell --- one of the circles that
Dante didn't describe.
26 May
26 May
6:59 a.m.
From: mark.kahrs at gmail.com
You know, it all depends on the person. Personally, I call the logic
analyzer the "tool of last resort" or "the dreaded logic analyzer".
When
you need it, you need it and nothing else will do. But often you can get a
long way with a 'scope and a logic probe (in the ancient days when strobes
were easily accessible).
When you're debugging a 32 bit bus and you've got probes hanging all over
the place, then you know you are deep in hell --- one of the circles that
Dante didn't describe.
Hi
Yes, I'd say the same.
Even then, I've found that the sequence to capture some special
event is beyond what the manufacture though anyone would
want to do.
One of the times I used one, I built a special outside circuit
just to condition the trigger.
Actually, I was thinking, one of the nicer things to have in general
is a ROM-ICE. Much quiker than blowing EPROMs with test
code.
I have one that I got a few months back but haven't had the
chance to play with it much.
Dwight
7:49 a.m.
On Thu, May 26, 2011 at 9:59 AM, dwight elvey <dkelvey at hotmail.com> wrote:
?Actually, I was thinking, one of the nicer things to
have in general
is a ROM-ICE. Much quiker than blowing EPROMs with test
code.
Oh, yeah.
?I have one that I got a few months back but
haven't had the
chance to play with it much.
I (still) have a couple of Grammar Engine ROM emulators (I used to
work with the founder) - a ROMulator and a PromICE - for what we did,
both products worked the same, and the ROMulator download application
was even available for VMS (because we compiled it for Grammar Engine
for them to distribute). For traditional embedded development (MCU
plus external ROM), they are awesome.
My first experience with ROM emulators was enough to sell me on them
for life - I was writing the firmware for our VAXBI version of our
COMBOARD (a 68010 with 2MB of local RAM, 128K of local ROM, and a
Z8530 dual serial chip) and I was able to plug the ROMulator into our
target board, hang the box inside the VAXBI cage, then close the lid
on the thin serial cable. The arrangement allowed me to upload new
versions of the code without shutting down the VAX, pulling the board,
pulling the ROMs, replacing the ROMs, replacing the board, then
starting the VAX back up - I even put the upload commands at the end
of the Makefile, so rather than 30 minutes per revision cycle that
real EPROMs would have taken, we could get a new version of the code
running less than 5 minutes after saving the changes.
It's all easier now, of course, since modern microcontrollers have
onboard FLASH and it's trivial to push code over a serial or USB link,
with little or no external hardware, but in the 1980s, it was an
amazing thing.
-ethan
1:26 p.m.
My first experience with ROM emulators was enough to
sell me on them
My final year undergraduate project involved an embedded 6809 system. The
first thing I did was to build myself (not part of the offical project)
an EPROM prgorammer/emulator. Not having to erase EPROMs all the time was
great!
[Of course said programemr/emulator was controlled by a couple of boards
of TTL logic chips. I couldn't use a microprocessor because without the
programemr I had no way to burn the firmware ROMs...)
-tony
27 May
27 May
12:12 p.m.
On Thu, 26 May 2011 06:59:47 -0700
dwight elvey <dkelvey at hotmail.com> wrote:
Actually, I was thinking, one of the nicer things to
have in general
is a ROM-ICE. Much quiker than blowing EPROMs with test
code.
Over a decade ago (on topic! ;-) ) I build an embedded system around a
8051 derivate. The chip had build in Flash, but needed a programing
adapter to be flashed. So it would have been the typical, compile, pull
chip, "burn" it, put chip back, cycle for testing. Cumbersome.
So I designed the board with external RAM and EPROM. (Harvard
architecture) I made the external EPROM programm memory visible in the
upper 32 kB of data RAM and I used a SRAM chip insted of an EPROM during
developement. I put a simple serial bootloader into the build in flash
of said 8051 derivate. Thus I needed to programm the chip only once.
So developement was:
Assemble.
Put CPU in Reset state. (Via a switch on the target board.)
Enable internal FLASH. (Via a switch on the target board.)
Switch off reset, CPU starts RS232 bootloader from build in FLASH.
Download code into external programm memory by:
cat file.bin > /dev/tty01
Put CPU in Reset state.
Disable internal FLASH.
Switch off reset, CPU starts downloaded code from external SRAM.
Very convenient. Works as well as an EPROM emulator or some JTAG / ISP
stuff.
--
\end{Jochen}
\ref{http://www.unixag-kl.fh-kl.de/~jkunz/}
26 May
26 May
8:02 a.m.
On Wed, May 25, 2011 at 12:50, Mark Kahrs <mark.kahrs at gmail.com> wrote:
You know, it all depends on the person. ?Personally, I
call the logic
analyzer the "tool of last resort" or "the dreaded logic analyzer".
?When
you need it, you need it and nothing else will do. ?But often you can get a
long way with a 'scope and a logic probe (in the ancient days when strobes
were easily accessible).
As with everything, the logic analyzer is just a tool, and is the
right tool for those jobs that require a logic analyzer. If you're
debugging a sequencing circuit, or other heaps of logic that can't
easily be compartmentalized, it can be the tool that will solve the
problem in minutes rather than days.
Since these days most "random bunch of logic" is in FPGAs and their
ilk, pretty much every HDL development tool comes with a simulator
that is effectively a logic analyzer on virtual signals. And it's
very useful.
When I was working for Castleton debugging DSPs (I was hired as a
software guy) I shocked everyone by fixing a random intermittent
glitch by grabbing the board and hooking up the logic analyzer: I
found that one control signal was changing at the same time as the
clock signal, thus it wasn't always latched correctly. Got the
hardware guys to reprogram the FPGA to move the signal 1/4 clock ahead
in time, and the thing turned out to be rock solid. My boss had no
idea how I did it, and I gained major respect from the hardware group.
Joe.
--
Joachim Thiemann :: http://www.tsp.ece.mcgill.ca/~jthiem
12:01 p.m.
You know, it all depends on the person. Personally, I call the logic
analyzer the "tool of last resort" or "the dreaded logic analyzer".
When
Well, yes, I guess it is, in that you do the obvious checks (power supply
:-:), etc first, and maybe use a logic probe to see if anything is
obviously wrong (like one bus line stuck when all the others are changing.
But for digital troubleshooting, I grab the logic analyser next. Most of
the itme I need at least 8 and often more input channels. I can't afford
a DSO with that many inputs :-)
Of course it does depend on what I am working on. A logic analyser is not
a lot of help in repairing analogue stuff like SMPUs and (most) monitors.
you need it, you need it and nothing else will do.
But often you can get a
long way with a 'scope and a logic probe (in the ancient days when strobes
were easily accessible).
These are the 'ancient days' aren't they? This is classiccmp, and I am
talking about repaurubg classic computers.
When you're debugging a 32 bit bus and you've got probes hanging all over
the place, then you know you are deep in hell --- one of the circles that
Dante didn't describe.
I think it would be very difficult to repair an HP9800 machine or even an
HP9866 thermal printe (to name 2 ofd the devices that have been across my
bench recently) without a logic analyser. You might get lucky and find a
signal that's obviously way off, but much of the time you need to trace
the sequence of the microcode or control state machine (which are much
the same thing, actually...)
-tony
4963
days inactive
4965
days old
6 comments
6 participants
participants (6)
-
ard＠p850ug1.demon.co.uk -
dkelvey＠hotmail.com -
ethan.dicks＠gmail.com -
jkunz＠unixag-kl.fh-kl.de -
joachim.thiemann＠gmail.com -
mark.kahrs＠gmail.com