What happens when your program crashes?

I

Ian Collins

Richard said:
So what? You can pass all the unit tests you want and it still doesn't
stop the entire application having bugs.

He was talking about adding new code, not debugging. Is there an echo in
here?
 
C

CBFalconer

Ian said:
jacob navia wrote:
.... snip ...


But that's a one off manual process. If you write a unit test
to validate the change, it becomes part of your automated test
suite which can be run each time you build.

I think I have seen evidence that Jacob has no test suite.
 
A

Anand Hariharan

But let's face it, a debugger is a real time saver.

The problem with a debugger is that it could significantly change
the behaviour of a program that is already riddled with undefined
behaviour. A debugger tends to be more forgiving of a program's UB
(e.g., it would initialise all uninitialised variables), and hence
can make locating bugs more difficult.

On the other hand, contrary to what many would say in this group, I
don't find C to be a simple language at all -- I guess I am but a
mere mortal. It is extremely easy to go wrong and worse, not know
that you have gone wrong. To that end, I would favour any tool that
helps me identify those cases where I have gone wrong (something
that I would not be able to do by reading the code).

- Anand
 
A

Anonymous

It is extremely easy to go wrong and worse, not know
that you have gone wrong. To that end, I would favour any tool that
helps me identify those cases where I have gone wrong (something
that I would not be able to do by reading the code).

If your code runs on Linux, I suggest you look at Valgrind. It is a
remarkable tool for identifying and debugging common memory errors and
leaks (using uninitialized variables, unfreed memory, double frees, out-
of-bounds array accesses, etc).
 
R

Richard Heathfield

Anand Hariharan said:
The problem with a debugger is that it could significantly change
the behaviour of a program that is already riddled with undefined
behaviour. A debugger tends to be more forgiving of a program's UB
(e.g., it would initialise all uninitialised variables), and hence
can make locating bugs more difficult.

All certainly true, although that's *a* problem with a debugger, not *the*
problem.
On the other hand, contrary to what many would say in this group, I
don't find C to be a simple language at all

Compare it to COBOL, Fortran, C++, Java (incl libs), or C#.NET
-- I guess I am but a mere mortal.

"Simple" doesn't mean quite the same as "easy". Ook! is simpler than C, but
it is easier to write programs in C than in Ook!
It is extremely easy to go wrong and worse, not know
that you have gone wrong. To that end, I would favour any tool that
helps me identify those cases where I have gone wrong (something
that I would not be able to do by reading the code).

Absolutely right. But ask yourself how you would feel if you were forced to
use such a tool even in situations where it *doesn't* help you. And how
would you feel if you were called a liar for claiming that there are such
times?
 
J

jacob navia

CBFalconer said:
I think I have seen evidence that Jacob has no test suite.

The evidence is that your brain seems damaged falconer!

In one test suite I have
21877 lines in 351807 bytes with 603 files
In another
24390 lines in 727447 bytes with 41 files

and several smaller ones scattered around.
 
F

Flash Gordon

jacob navia wrote, On 18/03/08 23:24:

The above is a description of debugging in a workstation type
environment. In other environments, this whole stuff is much more
difficult.

No, spend the money on a proper In-Circuit emulator and it is easy. Some
processors actually have JTAG built in which makes it easier still since
the "In-Circuit Emulator" is replaced with a simple JTAG interface and
your debugger takes over the processor using that.
Take the lcc-win debugger when used with a 16 bit DSP of Analog devices
(80-90K of RAM + 512K EPROM).

For starters, there is no possibilities of breakpoints. Eproms can be
written in 4K chunks, and setting/unsetting breakpoints like that
is out of the question.

<snip>

Not a problem with an ICE as you don't insert the break points by
changing the code, the ICE monitors the internals of the processor and
breaks it at the appropriate point.

The In-Circuit Emulator was old technology in the mid 80s (the ICE I was
using was years old, and I mean the actual box was old, the design was
even older) and JTAG came on line in the 90s. I suggest you need to
learn enough so that you are less than 20 years out of date before
lecturing about debuggers in the embedded world.

I also suggest you take this somewhere it is topical.
 
A

Anand Hariharan

Anand Hariharan said:


Compare it to COBOL, Fortran, C++, Java (incl libs), or C#.NET


"Simple" doesn't mean quite the same as "easy". Ook! is simpler than C, but
it is easier to write programs in C than in Ook!

Are you suggesting that each time someone says C is simple, what they
really mean C is simpl_er_ than other mainstream programming
languages?

Absolutely right. But ask yourself how you would feel if you were forced to
use such a tool even in situations where it *doesn't* help you.

Like turning on compiler warning levels to the maximum, for
example? ;-) As you noted recently in one of the recent threads,
there might be so many warnings in a non-trivial project, that they
tend to become noise that you start to ignore.

I think we can all agree that there is no silver bullet.

And how would you feel if you were called a liar for claiming that there are such
times?

That would be totally uncalled for, I agree.

- Anand
 
J

jacob navia

Flash said:
jacob navia wrote, On 18/03/08 23:24:



No, spend the money on a proper In-Circuit emulator and it is easy.

Of course!

SPEND THE MONEY!

How could I forget that?

Jacob:
Here is a description of how you start your car:
... You put in the keys, then...

Flash Gordon:
You do not need that if you buy your Rolls Royce with
integrated chauffeur. Just tell him where you want to go.

(and goes on with a rolls description)

You are behind 20 years pal...


There are people that *need* to have the last word.
"Gordon" seems one of those!
Some
processors actually have JTAG built in which makes it easier still since
the "In-Circuit Emulator" is replaced with a simple JTAG interface and
your debugger takes over the processor using that.

Sure sure. And the JTAG (whatever) interface will find the
source code and display it in a windows machine?

No. Your expensive interface just spares the easiest part of
debugging: writing the small in circuit monitor
<snip>

Not a problem with an ICE as you don't insert the break points by
changing the code, the ICE monitors the internals of the processor and
breaks it at the appropriate point.

And you buy one of those for each embedded processor you re working
with. OBVIOUS.

The In-Circuit Emulator was old technology in the mid 80s (the ICE I was
using was years old, and I mean the actual box was old, the design was
even older) and JTAG came on line in the 90s. I suggest you need to
learn enough so that you are less than 20 years out of date before
lecturing about debuggers in the embedded world.

Sure. Just spend the money. GREAT SOLUTION!
 
R

Richard Heathfield

Anand Hariharan said:

Are you suggesting that each time someone says C is simple, what they
really mean C is simpl_er_ than other mainstream programming
languages?

Well, it's simpler than the more complicated ones, yes. But not as simple
as the simpler ones. :) But, as I said, "simple" doesn't necessarily
equate to "easy".
Like turning on compiler warning levels to the maximum, for
example? ;-) As you noted recently in one of the recent threads,
there might be so many warnings in a non-trivial project, that they
tend to become noise that you start to ignore.

Good example. Generally, when I'm teaching newbies to program, I get them
to crank the warning level up to the max, and aim for a clean compile. At
some point, they discover that some of the warnings really /are/ noise
that is best ignored. The trick is to know which ones, of course.

By the time someone has learned to deal properly with *all* the warnings
they get, they're probably ready to start turning some of the sillier ones
off (e.g. the gcc warning for int foo[X] = {0};).
I think we can all agree that there is no silver bullet.

It appears not. Some people seem to think a debugger /is/ a silver bullet,
the sine qua non of debugging. And I think that's just daft.
 
J

jacob navia

Flash said:
The In-Circuit Emulator was old technology in the mid 80s (the ICE I was
using was years old, and I mean the actual box was old, the design was
even older) and JTAG came on line in the 90s. I suggest you need to
learn enough so that you are less than 20 years out of date before
lecturing about debuggers in the embedded world.

The problems with JTAGS are many...
1) It is a proprietary interface that you need to buy to the
manufacturer and that comes with a proprietary program under windows
only, that drives the chip and cable.

2) JTAGS stops the processor completely. This can be useful in some
contexts, but many customers prefer a less intrusive debugging setup
where the monitor runs as a normal program under the embedded mini-OS
and allows that other processes go on without stopping everything
in the processor.

3) The documentation for this setup is very difficult to find, and
changing/using it is an awful amount of work. Much more than
writing the monitor in the chip.

4) A lot of older processor do not support JTAGS at all.

Obviously, you are working for the military/big companies where
money is not an issue.

I am working with smallish electronic companies that do not have
the budgets/time to develop and use the JTAGS environment and
prefer to spend a bit more maybe, but to have a compiler and
debugger with source code that they can configure without any
restrictions.
 
C

Charlton Wilbur

RH> Debugging unseen code is *usually* impossible (which is why we
RH> ask people here to show us their code) - but *sometimes* it
RH> can be done, and although it creates a great impression, it
RH> normally only happens when the code's author is a relative
RH> newcomer to C or to programming, and has stumbled into a
RH> common trap.

The latter, alas, does not require the former; your conjunction should
be a non-exclusive disjunction.

Charlton
 
F

Flash Gordon

jacob navia wrote, On 20/03/08 15:26:
The problems with JTAGS are many...
1) It is a proprietary interface that you need to buy to the
manufacturer and that comes with a proprietary program under windows
only, that drives the chip and cable.

Ah, so IEEE Std. 1149.1-1990 is a proprietary interface used by Texas
Instruments (where I first came across it), Intel...

I'm also interested to hear that GDB under Linux is a proprietary
program under Windows. For example http://openocd.berlios.de/web/

Try actually looking at what things are before you complain about them.
2) JTAGS stops the processor completely. This can be useful in some
contexts, but many customers prefer a less intrusive debugging setup
where the monitor runs as a normal program under the embedded mini-OS
and allows that other processes go on without stopping everything
in the processor.

Sometimes what you need is to stop all of the processors, otherwise your
communications channels time out. I was using a JTAG based system to
simultaneously stop 20 processor cores spread across 4 chips, and only
stopping one would have been pointless.
3) The documentation for this setup is very difficult to find, and
changing/using it is an awful amount of work. Much more than
writing the monitor in the chip.

Took me 30 seconds to find the OpenOCD project. Doesn't seem lime an
awful amount of work to me. Also, of course, there are the projects
4) A lot of older processor do not support JTAGS at all.

Aren't you the one always telling us those older processors do not
matter? In any case, using that as an argument against my post is
disingenuous. I mentioned In-Circuit Emulators as well, and those are
available for older processors such as the Z80, 8051, 6502 etc.
Obviously, you are working for the military/big companies where
money is not an issue.

You've obviously not worked in the defence industry or for a large
company, getting approval for large expenditure is not easy because
money *is* an issue.
I am working with smallish electronic companies that do not have
the budgets/time to develop and use the JTAGS environment and

Development time, 0. Use an off-the-shelf product. Cost for a JTAG
adapter, 129 Euros. http://www.amontec.com/
Yes, you also have to put the appropriate connector on the circuit
board, but that is not expensive or difficult either, and it took only
seconds to find the pinout for this one
http://www.amontec.com/jtag_pinout.shtml

Before you complain that does not support your specific processor, there
are plenty of others or, as I mentioned, older In-Circuit Emulators.
prefer to spend a bit more maybe, but to have a compiler and
debugger with source code that they can configure without any
restrictions.

Well, perhaps they should spend a bit less and have an open source
compiler and debugger with source code that they can configure without
restriction and the added advantage of being able to set break points
even when the code is in ROM.
 
J

jacob navia

Flash said:
jacob navia wrote, On 20/03/08 15:26:

Ah, so IEEE Std. 1149.1-1990 is a proprietary interface used by Texas
Instruments (where I first came across it), Intel...

This is *bogus*. There is no standard since every chip manufacturer
does extension over extensions and without them this stuff just
doesn't work!
I'm also interested to hear that GDB under Linux is a proprietary
program under Windows. For example http://openocd.berlios.de/web/

Try actually looking at what things are before you complain about them.

I am not complaining about anything. I am just explaining things to you.
Sometimes what you need is to stop all of the processors, otherwise your
communications channels time out. I was using a JTAG based system to
simultaneously stop 20 processor cores spread across 4 chips, and only
stopping one would have been pointless.

You were doing a completely different thing. Who cares? I need to keep
the processor/OS running and do NON INTRUSIVE debugging!

Took me 30 seconds to find the OpenOCD project. Doesn't seem lime an
awful amount of work to me. Also, of course, there are the projects

I am speaking about the JTAGS setup and the proprietary extensions
of each chip.
Aren't you the one always telling us those older processors do not
matter? In any case, using that as an argument against my post is
disingenuous. I mentioned In-Circuit Emulators as well, and those are
available for older processors such as the Z80, 8051, 6502 etc.

Those are quite expensive too.
You've obviously not worked in the defence industry or for a large
company, getting approval for large expenditure is not easy because
money *is* an issue.

I said that *for you* money is not an issue since YOU started your
answer with

SPEND THE MONEY!
Development time, 0. Use an off-the-shelf product.

I see: "Buy an off the shelf compiler".

Well, this is not something the companies I work with want to do for
many reasons, specially the absolute opacity of the proprietary
solutions.
Cost for a JTAG
adapter, 129 Euros. http://www.amontec.com/
Yes, you also have to put the appropriate connector on the circuit
board, but that is not expensive or difficult either, and it took only
seconds to find the pinout for this one
http://www.amontec.com/jtag_pinout.shtml

Before you complain that does not support your specific processor, there
are plenty of others or, as I mentioned, older In-Circuit Emulators.


Well, perhaps they should spend a bit less and have an open source
compiler and debugger with source code that they can configure without
restriction

No.

1) That stuff is "OPEN SOURCE" and they do not want
any GNU stuff. My system is NOT open source
precisely.

2) GDB is a monster debugger, like its cousin GCC. Yes,
it is much more bloated anything jacob can ever do,
but that was one of my major selling points:

GCC+GDB is around 30MB of C.
lcc + debugger is around 3MB of C.

Which one would you like to configure and maintain ?
and the added advantage of being able to set break points
even when the code is in ROM.

I explained how to do that in my post. You did not read that
apparently because anyway what I say is always wrong.
:)

Conclusion:

I present simple solutions for debugging embedded systems
coupled with a simple compiler that produces a system that is
easy to maintain, configure and debug.
 
F

Flash Gordon

jacob navia wrote, On 20/03/08 14:46:
Of course!

SPEND THE MONEY!

Well, 1500USD is generally a small fraction of the costs of SW
development on any project. It would not even buy you one day of my
time! I suppose it might buy you a two or three weeks of an Indian
developers time, but you say that a decent debugger saves a lot of time
so that should pay for itself easily.

By the way, I'm not joking about the price, although some are more. It
hardly took me any time to find
http://www.metaice.com/Files/8051_Price_List.pdf
How could I forget that?

Jacob:
Here is a description of how you start your car:
... You put in the keys, then...

Flash Gordon:
You do not need that if you buy your Rolls Royce with
integrated chauffeur. Just tell him where you want to go.

(and goes on with a rolls description)

You are behind 20 years pal...

Nope. Something closer would be:

Jacob:
Here is a description of how a car works...

Flash:
Just go out and buy a car, they have been available for a long time.
There are people that *need* to have the last word.
"Gordon" seems one of those!

No, I just don't like to see people being mislead.
Sure sure. And the JTAG (whatever) interface will find the
source code and display it in a windows machine?

No, the debugger you use through it does that.
No. Your expensive interface just spares the easiest part of
debugging: writing the small in circuit monitor

Wrong, you get the debugger off the shelf as well. In fact, I've yet to
come across an ICE that did *not* come with a debugger, and since I
moved away from assembler I've yet to find one that did not support C.

Well, the emulator I found in next to no time costs 2000USD for the
version that supports this processor. However I did not look hard and
stopped after the first one I found.
And you buy one of those for each embedded processor you re working
with. OBVIOUS.

No, almost all of them support entire ranges of processors. For example
at 1500USD buy one that supports:
8x31/32/51/52/54/58, C501
8xC31X2/32X2/52X2/54X2/58X2
8xC51FA/FB/FC, 8xC51RA/RB/RC/RD
Atmel AT89C51ED2, AT89C51RB2/RC2/RD2, T8xC51RA2/RB2/RC2
NXP (Philips) P8xC51RA+/RB+/RC+/RD+, P8xC51RA2/RB2/RC2/RD2
NXP (Philips) P8xC60X2/61X2
Sure. Just spend the money. GREAT SOLUTION!

Actually, it is a great solution when you need to run a debugger on the
hardware. It is also great for proving that the hardware is faulty,
something I have done more than once. As with any tool it is not perfect
for all situations. However the cheap ones are cheap compared to SW
development costs.

Now, if you want something expensive I can recommend Lauterbach, but
that involves some serious expenditure, but as I say the low end is in
the low 4 figures USD (or 3 figures UKP). However, you will not have to
change most of the HW when you change processor as it supports shed
loads. BTW, looking at their site I see they have improved it a lot
since I decided it was worth the small fortune it cost (I bought 2 plus
some training and development to support a compiler they did not do at
that time (Tek Pascal, still on their supported list) for 50000UKP in
the 90s, so over 10 times the price of the cheap ones).

I have also used monitors running on the processor, but I've always
found an ICE to be far more powerful.
 
J

jacob navia

Flash said:
jacob navia wrote, On 20/03/08 14:46:

Well, 1500USD is generally a small fraction of the costs of SW
development on any project. It would not even buy you one day of my
time! I suppose it might buy you a two or three weeks of an Indian
developers time, but you say that a decent debugger saves a lot of time
so that should pay for itself easily.

Well, besides your incredible arrogance, personally I wouldn't pay a
PENNY for your time.

Indian programmers can also have high salaries didn't you know?

They are just as clever as you.

But coming back to the tools I develop.

Their advantage is that they can be precisely and in a short time be
configured to the customer software environment. To the OS they
run, and specifically to the type of software they run.
By the way, I'm not joking about the price, although some are more. It
hardly took me any time to find
http://www.metaice.com/Files/8051_Price_List.pdf


Nope. Something closer would be:

Jacob:
Here is a description of how a car works...

Flash:
Just go out and buy a car, they have been available for a long time.


No, I just don't like to see people being mislead.

I am not misleading anyone. I described a different type of
debugger than what you use.
No, the debugger you use through it does that.

Well, that's my point! You have to write the debugger anyway. The *only*
thing JTAGS saves you is the writing of the software in-chip that
will supervise the running program.
Wrong, you get the debugger off the shelf as well. In fact, I've yet to
come across an ICE that did *not* come with a debugger, and since I
moved away from assembler I've yet to find one that did not support C.

OK. Then use it. I was describing a *different* stuff.
Well, the emulator I found in next to no time costs 2000USD for the
version that supports this processor. However I did not look hard and
stopped after the first one I found.

But it does NOT support the OS this people use, nor the way their
software works!

Obviously you do not want to understand. The only objective here
is to show others how clever you are.
 
F

Flash Gordon

jacob navia wrote, On 20/03/08 19:38:
This is *bogus*. There is no standard since every chip manufacturer
does extension over extensions and without them this stuff just
doesn't work!

See below for a system I pointed you at which supports multiple processors.
I am not complaining about anything. I am just explaining things to you.

So address the point I raised just above the line you commented on.
Namely the OpenOCD project which runs uses software running under Linux
(when you said the software has to run on Windows) and is free.
You were doing a completely different thing. Who cares? I need to keep
the processor/OS running and do NON INTRUSIVE debugging!

So use the trace and watch facilities of the ICE to monitor things
without stopping any processes.

In any case, you started off talking about using a debugger *without*
mentioning non-intrusive debugging, in fact you were talking about
debugging a crash, and crashes are normally fairly intrusive! You really
should stop moving the goal posts as soon as anyone comes up with a
counter example.
I am speaking about the JTAGS setup and the proprietary extensions
of each chip.

Now address the point that the project exists and provides the software
and other information required to use JTAG on those chips. Either they
have found out the details of those proprietary extensions so them being
proprietary is not a problem (you don't need to do the work, it has
already been done) or it works without them.
Those are quite expensive too.

No, see other post. You could double the cost by buying a day of my time
as a consultant to find them for you.
I said that *for you* money is not an issue since YOU started your
answer with

SPEND THE MONEY!

Ah, but when I was working on embedded SW I was working for *exactly*
the type of company you mention above, a big company doing work for the
military. Money *is* an issue in such companies, so it was an issue for
me when I was involved in such things. However, the entry level for them
is NOT expensive compared to a week of a developers time.
I see: "Buy an off the shelf compiler".

Where above did I say, "buy an off the shelf compiler"? I've rechecked
everything I typed and that does not exist anywhere. Specifically, the
OpenOCD project uses gdb so you can use any compiler that produces a
format gdb can cope with, such as gcc.
Well, this is not something the companies I work with want to do for
many reasons, specially the absolute opacity of the proprietary
solutions.

Ah, so gcc is a proprietary solution but your debugger is not.
Interesting definitions you have.

So you accept that it can be cheap then?

So you accept the information is easily available then?
No.

1) That stuff is "OPEN SOURCE" and they do not want
any GNU stuff. My system is NOT open source
precisely.

So buy one of the cheap solutions that is not open source.
2) GDB is a monster debugger, like its cousin GCC. Yes,
it is much more bloated anything jacob can ever do,
but that was one of my major selling points:

GCC+GDB is around 30MB of C.
lcc + debugger is around 3MB of C.

Which one would you like to configure and maintain ?

gdb, it is heavily used and maintained by a team rather than an individual.
I explained how to do that in my post. You did not read that
apparently because anyway what I say is always wrong.
:)

Sorry, did I forget to say "vast numbers of" in the above? In fact, for
one of the Analog Devices processors the ICE mentions 128Kb Hardware
Breakpoints. Also 64K frames of trace memory, i.e. it can store 65536
events in its buffer whilst the processor is running full speed
including at least some registers, so you can wind back that far after
you have hit a break point?
Conclusion:

I present simple solutions for debugging embedded systems
coupled with a simple compiler that produces a system that is
easy to maintain, configure and debug.

Your system is also proprietary (which you claim is bad), requires extra
code running on the device slowing it down, has no trace to look back at
the program execution that lead up to the event of interest, ties you
for support to a one-man-band (a show stopper for some companies), ties
you to a specific compiler and language (a show stopper for some
companies), is of limited use for debugging HW problems (how do you use
it if the problem crashes the monitor?), cannot be used to upload and
test a new version of the software (how do you upload in to ROM? an ICE
has RAM in it you can use instead) etc.

Have you used a real ICE?

So how much do you charge a customer *including* technical support? Less
than 2000USD?
 
J

John Bode

Anand Hariharan said:

[snip]
On the other hand, contrary to what many would say in this group, I
don't find C to be a simple language at all

Compare it to COBOL, Fortran, C++, Java (incl libs), or C#.NET

I had a *much* easier time understanding and working in Fortran (77)
than C when I started out. After the nightmare that was our intro C
class, Fortran felt like the rock in the midst of a raging torrent.
And I wouldn't say Cobol isn't simple, just that it's tedious as hell
to write.

Java and C# I'll give you, mainly due to the class libraries.
 
F

Flash Gordon

jacob navia wrote, On 20/03/08 20:11:
Well, besides your incredible arrogance, personally I wouldn't pay a
PENNY for your time.

Indian programmers can also have high salaries didn't you know?

I've worked with them (I spent about 4 months in India with them as well
as time in the UK), have you? I've discussed with managers what their
salaries are, have you? There salary is a *lot* less than the rate my
time is charged out at. Perhaps I should have said, "Indian developers
in India", but I thought it was obvious, just as it was obvious that I
did not mean Native Americans.
They are just as clever as you.

I did not make any comment about their abilities, only about the
relative cost of their time to an ICE.
But coming back to the tools I develop.

Their advantage is that they can be precisely and in a short time be
configured to the customer software environment. To the OS they
run, and specifically to the type of software they run.

So can an the software for an ICE. I know because I have had this done!
I am not misleading anyone. I described a different type of
debugger than what you use.

Your comment, "The above is a description of debugging in a workstation
type environment. In other environments, this whole stuff is much more
difficult." was misleading, since from the perspecitve of a developer at
least it is actually *easier* with an ICE because you have a lot more
control and things like 64K trace buffers that do not slow down
execution of the program (if it is much more difficult in your system
that is a problem with your system). Your comments about the cost of an
ICE were misleading. Your characterisation of my position above was
misleading.
Well, that's my point! You have to write the debugger anyway. The *only*

No you DO NOT. The debugger either comes with the kit or is freely
available. Or are you claiming that I have got to write gdb in order to
use it? I certainly did not write the emulator that Texas Instruments
provided with there JTAG based system for the TMS320C25, a system that
allowed me to do synchronised work across 25 processor cores.
thing JTAGS saves you is the writing of the software in-chip that
will supervise the running program.

You obviously still do not understand the position of a user. I use the
JTAG kit provided by a supplier (you can get some for one 139 Euros I
think it was, although I'm sure there are more expensive options) and
use the debugger it is designed to work with (either GDB if it uses
OpenOCD, or whatever else is appropriate including in some instances a
debugger packaged with the kit). *I* don't have to write a debugger or
debug it. The same applies to users of *your* package, they don't have
to write the debugger it is _the_supplier_ that does that.
OK. Then use it. I was describing a *different* stuff.

You said, "It would be interesting to hear from people that use
debuggers in other embedded systems to share their experiences here." So
you should be very interested in the truth about using an ICE or JTAG
based debugger rather than your obviously incorrect assumptions.
But it does NOT support the OS this people use,

If you want one that supports an OS you can buy one that supports an OS,
lots of them do. For example the one from Wind River which supports
vxWorks on multiple processors.
nor the way their
software works!

You customise your debugger for the application being debugged? Here was
me thinking that debuggers were general purpose tools useful for any
application. I certainly would not want to have to replace the debugger
just because I was debugging different software! However, at least some
ICE do allow you to do all sorts of things to customise them for the way
the SW works, such as monitors for specific protocols and the ability to
write your own protocol definitions
Obviously you do not want to understand. The only objective here
is to show others how clever you are.

No, the objective is to give you another perspective and let you know
about the very powerful tools out there which you seem to be ignorant of.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top