EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

how important is an emulator to an embedded engineer?

Started by Unknown August 8, 2004
I am going to do some embedded work with 80's technology.

vax, 3900
-- 
http://www.geocities.com/mscpscsi
vax3900 wrote:
> I am going to do some embedded work with 80's technology. > > vax, 3900
I say that if your load/run/test cycle is more than about 30 seconds to 2 minutes on the target hardware, or if the target hardware is not availiable or always available, then an emulator makes some sense. Or if you cannot printf (or output strings) from the target. Makes some sense when learning about the specfic registers, if you're not really familiar with the processor. There are some negatives to emulators. Simulating inputs and interrupts accurately is difficult. -- ------------------------------------------------------------ Creepy, Soulless Gigolo for President ? NOT ! --------------------------------------------- THK is one weird, weird something.
> I am going to do some embedded work with 80's technology. >
Depending how much of the software is target dependent. The company I work for supports various hardware platforms, and one of the handy tools is our "Windows emulator". It shares all the device independent code (90% in our situation) and solves the problem of having less (often expensive) emulators than developers. Also, the Visual C debugger is better than many debuggers for embedded systems (and more familiar) Wim
Bryan Hackney wrote:

> vax3900 wrote: >> I am going to do some embedded work with 80's technology. >> >> vax, 3900 > > I say that if your load/run/test cycle is more than > about 30 seconds to 2 minutes on the target hardware, or if > the target hardware is not availiable or always available, then > an emulator makes some sense. > > Or if you cannot printf (or output strings) from the target. > > Makes some sense when learning about the specfic registers, if > you're not really familiar with the processor. > > There are some negatives to emulators. Simulating inputs and > interrupts accurately is difficult. >
Then it seems I don't need one. I use 80188, so that I can test most of the codes on PC. I design a serial port for it, so that I can printf to a terminal. Also I am familiar to x86 enough, and I design my board as an ISA board so that I can download program to on board SRAM from PC. Thanks. vax, 3900 -- http://www.geocities.com/mscpscsi
vax3900 wrote:

> I am going to do some embedded work with 80's technology.
An emulator is slightly better than a printf as it allows to read all variables and registers at the breakpoint. It is equally useless to debug realtime data though. Eg when you have to keep up with a cummunication channel or with a control loop. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net
Rene Tschaggelar wrote:
> vax3900 wrote: > >> I am going to do some embedded work with 80's technology. > > > An emulator is slightly better than a printf as it allows > to read all variables and registers at the breakpoint. > > It is equally useless to debug realtime data though. > Eg when you have to keep up with a cummunication channel > or with a control loop. > > Rene
> Not if the emulator has a real-time trace buffer that supports flexible start/end triggers and filters.
vax3900 wrote:

> Then it seems I don't need one. I use 80188, so that I can test most of the > codes on PC. I design a serial port for it, so that I can printf to a > terminal. Also I am familiar to x86 enough, and I design my board as an ISA > board so that I can download program to on board SRAM from PC. Thanks. >
Depending on your application, you may find that using an In-Circuit Emulator or ICE will save you a lot of grief, and reduce your debugging time from days to hours. Using printf's requires you to keep editing, recompiling, and downloading the program. This can be very tedious and adding the printf's can sometimes change the symptoms. The source of some problems like null pointers or an unexpected change in a variable value can be very difficult to find without an ICE that allows you to trap on a write or read to/from an address range, possible using a data expression. If you can get your hands on an old Checkmate or AMC CodeTap ICE for the 80188, that would be very helpful. Also consider the use of a remote debugger approach. You put a small monitor driver in your application that uses your serial port for communication with a driver running on the PC host. You then run an application similar to Turbo Debug on the PC that communicates with the monitor in the 80188 to permit you to examine variables, set breakpoints, single step, etc. Paradigm Debug/RT is an example of this approach http://www.testech-elect.com/paradigm/p_debug_rt.html You can also use a ROM emulator for downloading and debugger communication or use the SRAM window in your ISA board for a communication channel. The latter approach requires you to write a DOS driver and matching code that interfaces to the remote debug monitor on the 80188 side. Some of the better ROM emulators allow you capture realtime traces of your program execution or break on address expressions like an ICE would, see for example the Grammar Engines PromIce. One URL is http://www.forthinc.demon.co.uk/gendev/grammar.htm. Tom Taylor
"vax3900" <vax3900@yahoo.com> wrote in message
news:cf4afn$33t$1@charm.magnus.acs.ohio-state.edu...
> I am going to do some embedded work with 80's technology.
That depends on many factors: - resources available - development schedule - the language(s) you intend to use - the reliability of the targeted hardware - whether this is an "original" work of your own - the complexity of the application - how well you understand the technology you are applying - how robust the finished product must be - your (personal) coding/debugging methodology I've designed products with and without the "assistance" of emulators. And, devices *claiming* to be emulators that were little more than "rom emulators" with a CPU attached. For a variety of reasons, I have stopped using them on projects that I control. If you are strapped for (financial/space/etc.) resources, an emulator might be ruled out. It takes time to select/buy/rent one; money (justification, contract reviews, etc.) for the purchase; time for it to be delivered; space to set it up; "issues" resolving compatibility with your prefered operating environment; etc. The emulator itself may have hardware and/or software/firmware "issues". So, instead of spending your time debugging your software, you are now debugging your *tools* (while *you* might get paid for this, your *employer* doesn't -- and, chances are, will not look favorably on your "excuse" that you have been busy troubleshooting bugs in the tools instead of "doing your job".) Source level debuggers often necessitate the use of a particular language/compiler to realize their full benefit. What is the quality of *that* tool? Is it produced by the same vendor as the emulator? Or, do you have yet another party involved in this? Customer: "The debugger is buggy" Debugger vendor: "No, the compiler is producing crappy code" Compiler vendor: "Not a chance -- the customer's hardware is flakey" Is this an "original work" of your own? Or, are you stepping in and maintaining/completing someone else's design? How well do you understand the design, the technology and the behaviours of the various algorithms involved? And emulator is a poor, expensive and inefficient means of "figuring out whats going on". If you don't know what to *expect* from the code and the mechanisms tying it together, then an emulator is a poor substitute for a good grounding in the design! Similarly, how complex is the application? Can it be simulated at DC? Or, does it involve lots of intricate timing relationships from external stimuli, etc.? Can you realistically "control" thos stimuli so that they will be there when and as often as needed for an emulator to catch their effects? Sure, an ICE may have a trace buffer with conditional qualifiers and triggers, etc. But, will you be able to EFFECTIVELY use them to capture "your experiment"? Will the trace buffer be deep enough (e.g., if you are writing in C++, you might exhaust the trace buffer just instantiating a "temporary" of a particular object -- yet, how can you get finer grained control over trace buffer triggers when your *source* hides all these mechanics inside a single statement or *expression*?) Are the tools for browsing the trace buffer adequate? Or, does it just reduce to a bunch of "bus cycles" ("gee, I wonder what the code is doing here...") Some would argue that hardware of dubious quality merits the use of an emulator "to track down hardware problems". I'm no longer of that mindset; if the hardware is flakey, get someone to redesign it. If your boss/client will tolerate flakey hardware, then why worry about producing "quality code"? (cynicism) Unless you are *really* working on bleeding edge technology, you shouldn't have to put up with flakey hardware. If you fall into the trap of "proving you found a hardware bug" (with the use of your emulator), you will be stuck doing this for the life of the project. If you suspect a bug, write a short, concise test case that exercises the bug. When it doesn't work as expected, hand it to the hardware designer and ask him/her to find the bug in your *code* (if it's OK for you to be coerced into troubleshooting hardware, then it is equally acceptable for the hardware personnel to be coerced into troubleshooting your software -- to prove that it is NOT their hardware that is at fault). How robust must the finished product be? Sure, everyone *claims* they produce "quality products" but, realistically, we *know* that's not the case. How insistent is "Management" that your product *truly* be "of the finest quaity" -- vs. "that's good enough, ship it"? *Will* they shut down the line to track down some elusive bug? Or, will they rationalize that it isn't THAT serious (and pay "lip service" to any customer that *might* complain about it later)? Will they gloss over bugs that aren't "hard and fast" (reproducible) and write them off as "a fluke"? Or, does every observed bug *demand* resolution? But, most important in your emulator choice is your own personal coding/debugging style. If you are the type that *designs* your application and identifies the likely failure modes and addresses them ahead of time, you probably won't gain much from the use of an ICE (all else being equal). Chances are, you can design algorithms in such a way that they can be driven by test cases and observed at DC using a desktop debugger/simulator. Here, you are simply trying to *verify* proper operation of your algorithms. Drive them with "unexpected" inputs to verify that they handle them predictably, etc. The final application essentially being created by assembling a group of "known good" modules that have already been bench-tested. If, on the other extreme, you sit down and start writing code on Day 1 without a clear and formal notion of where that code is *going*, then you'll probably LOVE having an emulator. It will let you "tinker". When you happen to catch something behaving in a way you hadn't anticipated, you'll (possibly) be able to walk through the code and see where it is defying you. This approach seems to work well in environments where employers want to "see" progress. As long as you are putting bugs behind you, the *perception* is that you are getting closer to your (*their*!) goal. Since few firms actually employ any metrics on the development process, this ends up being a crap shoot; *hopefully*, the number of bugs decreases. <shrug> Horses for courses. Figure out where your application environment sits in this continuum and make your decision based on the issues *you* observe firsthand. Sorry not to have a simple answer. But, hopefully, enough of the issues here to get you to think more honestly about the pros and cons of the choice. --don N.B. Incoming mail is unconditionally and silently discarded.
Don wrote:
> "vax3900" <vax3900@yahoo.com> wrote in message > news:cf4afn$33t$1@charm.magnus.acs.ohio-state.edu... > >>I am going to do some embedded work with 80's technology. > > > That depends on many factors: > - resources available > - development schedule > - the language(s) you intend to use > - the reliability of the targeted hardware > - whether this is an "original" work of your own > - the complexity of the application > - how well you understand the technology you are applying > - how robust the finished product must be > - your (personal) coding/debugging methodology > > I've designed products with and without the "assistance" of emulators. > And, devices *claiming* to be emulators that were little more than > "rom emulators" with a CPU attached. For a variety of reasons, I > have stopped using them on projects that I control. >
[...] Wow. What an answer. I'll file and read the whole thing later. Unqualified "emulator" means soft emulator, IME. -- ------------------------------------------------------------ Creepy, Soulless Gigolo for President ? NOT ! --------------------------------------------- THK is one weird, weird something.
Tom Taylor wrote:
> vax3900 wrote: > >> Then it seems I don't need one. I use 80188, so that I can test most >> of the >> codes on PC. I design a serial port for it, so that I can printf to a >> terminal. Also I am familiar to x86 enough, and I design my board as >> an ISA >> board so that I can download program to on board SRAM from PC. Thanks. >> > Depending on your application, you may find that using an In-Circuit > Emulator or ICE will save you a lot of grief, and reduce your > debugging time from days to hours. Using printf's requires > you to keep editing, recompiling, and downloading the > program. This can be very tedious and adding the printf's > can sometimes change the symptoms. The source of some problems > like null pointers or an unexpected change in a variable value > can be very difficult to find without an ICE that allows you > to trap on a write or read to/from an address range, possible using a > data expression. >
A long time ago, I worked with an EE who got stuck doing some coding. He got the 99/1 rule backwards. It should be 99% of your time in the editor, or at least thinking and staring at the code, and 1% in the interactive debugger. I'm not kidding. Now an interactive debugger is not an emulator, and neither is an ICE. But to assume that you will need one up front is to be pessimistic these days. -- ------------------------------------------------------------ Creepy, Soulless Gigolo for President ? NOT ! --------------------------------------------- THK is one weird, weird something.

The 2024 Embedded Online Conference