Need help on choosing ARM C compilers
David Liang
I am new to ARM world. Now we are on the stage of choosing a ARM C
compiler. Any suggestion will be very appreciated.
Based on my prelimiary study, ARM SDT 2.5 seems to be a standard
compiler, how about it? I need some voice from real life ARM developers.
There are some complains about it from developers on this newsgroup. They
said it was 'painful'. Why is it 'painful'? Can anyone there give me more
idea of it?
ARM now annouces a new ADS tools to replace its STD 2.5. As we expected,
it is very pricy. Any review of that? Is it worthy to pay some extra
money for it instead of useing SDT 2.5?
TIA,
Happy developing,
David
--
Please remove '-ns' in my email address if reply,
I don't want spams.
Grant Edwards
>I am new to ARM world. Now we are on the stage of choosing a ARM C
>compiler. Any suggestion will be very appreciated.
I'm just in the beginning stages of an embedded ARM project and
am using gcc. So far I like it. It's a solid compiler. I've
got source code but have never needed it because the support
you get from Cygnus is excellent. I'm talking about the
no-cost mailing list and newsgroup support -- it's way better
than support I've paid for from other embedded copiler vendors.
I don't know what you get if you pay Cygnus for support.
Somebody must come sit in your office, look over your shoulder
and fix problems before you notice them.
I've been using gcc for 10+ years, so it probably helps that
I'm already familiar with it. I've not tried the ARM SDT, so I
can't compare them directly.
--
Grant Edwards grante Yow! .. I wonder if I
at ought to tell them about my
visi.com PREVIOUS LIFE as a COMPLETE
STRANGER?
Neil Bradley
> I am new to ARM world. Now we are on the stage of choosing a ARM C
> compiler. Any suggestion will be very appreciated.
>
> Based on my prelimiary study, ARM SDT 2.5 seems to be a standard
> compiler, how about it? I need some voice from real life ARM developers.
> There are some complains about it from developers on this newsgroup. They
> said it was 'painful'. Why is it 'painful'? Can anyone there give me more
> idea of it?
I use the ARM 2.5 software on a daily basis with an EPI Jeeni via ethernet.
My issues are as follows:
* Asks "Do you want to start the debugger in remote debugging?" *EVERY* time
the app starts (which is a big deal for me because each time I do a run I
have to restart the app because there's no reset button and a reload won't
always work)
* If I shift focus from the ARM debugger to another app while the debugger is
running and try to come back to the ARM debugger, it won't respond to any
keystrokes/mouse messages. I have to shift to another application's focus and
then back to the ARM debugger to make it work again.
* No reset button on the debugger. Maybe this is my debugger hardware
(Jeeni), but I'm having lots of trouble beliving that a basic feature like
this was left out. What appears to be the reset button is greyed out on the
debugger task bar. ;-(
* If you reset your target out from underneath the application, the debugger
will crash, which causes you to have to kill it via the task manager and
restart the app
* Viewing of structural variables a bit kludgy. Maybe I'm spoiled by MSVC,
but it seems as if the debugger already knows about the variable names and
structures that it could figure out the values of the individual members
* As you're stepping through code, the debugger "caches up" the code being
debugged. That means if you're running out of RAM, and suddenly your referesh
goes away or the RAM changes out from underneath the debugger, the debugger
appears to be misexecuting the code. We chased this one for quite a while.
The ARM debugger (I'm running 2.50) seems like it'd be an excellent product,
but the above shortcomings make it painful to deal with for me. And judging
that the last release was November of 1998 and I've found no patches or
updates for these bugs, I'm not hopeful that they will be fixed any time
soon.
-->Neil
Grant Edwards
>* No reset button on the debugger. Maybe this is my debugger hardware
>(Jeeni), but I'm having lots of trouble beliving that a basic feature like
>this was left out. What appears to be the reset button is greyed out on the
>debugger task bar. ;-(
The Jeeni doesn't have the ability to control the reset pin on
the JTAG connector. I don't think that the ARM Ltd, Embedded
ICE does either, but I've spent more time with the Jeeni.
The rest of the issues seem like debugger bugs.
I use gdb...
--
Grant Edwards grante Yow! Finally, Zippy
at drives his 1958 RAMBLER
visi.com METROPOLITAN into the
faculty dining room.
mailm...@yahoo.com
Don't forget to try out the Green Hills ARM compiler. There are quite a
few nice things that come with their toolset. Feel free to email me
about it.
Mike
In article <MPG.12de9742f...@news.storm.ca>,
David Liang <david...@hotmail.com> wrote:
> Hi, real life ARM developers,
>
> I am new to ARM world. Now we are on the stage of choosing a ARM C
> compiler. Any suggestion will be very appreciated.
>
> Based on my prelimiary study, ARM SDT 2.5 seems to be a standard
> compiler, how about it? I need some voice from real life ARM
developers.
> There are some complains about it from developers on this newsgroup.
They
> said it was 'painful'. Why is it 'painful'? Can anyone there give me
more
> idea of it?
>
> ARM now annouces a new ADS tools to replace its STD 2.5. As we
expected,
> it is very pricy. Any review of that? Is it worthy to pay some extra
> money for it instead of useing SDT 2.5?
>
> TIA,
>
> Happy developing,
>
> David
>
> --
> Please remove '-ns' in my email address if reply,
> I don't want spams.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
Robert S. White
>
>I use the ARM 2.5 software on a daily basis with an EPI Jeeni via ethernet.
>My issues are as follows:
...
Good synopsis!
I've been working as an engineer for 25 years...the last 20 with
embedded systems software and after receiving and trying to use the
ARM SDT 2.5 for 1 day I can see that your observations are spot on!
Never before had to use NT WK 4.0 sp 5 Task Manager to kill a hung
app so many times! But the SDT does work especially after figuring
out the funny U.K. techno jargon for things like include file paths,
as compared to what mid-western states use for comparable terms...
it is NOT the same as MVC++ ! Oh well it is good not to be too
parochial and be able to figure out how others from a different
culture may have chosen to name certain technical terms. :-)
_____________________________________________________________________
Robert S. White -- An embedded systems software engineer
e-mail reply to reverse of ( add .'s ): com home shift2 rswhite
or do a "Reply To All" for direct eMailed cc'd followups.
Robin Mitra
Neil Bradley schrieb:
> David Liang wrote:
>
> > I am new to ARM world. Now we are on the stage of choosing a ARM C
> > compiler. Any suggestion will be very appreciated.
> >
> > Based on my prelimiary study, ARM SDT 2.5 seems to be a standard
> > compiler, how about it? I need some voice from real life ARM developers.
> > There are some complains about it from developers on this newsgroup. They
> > said it was 'painful'. Why is it 'painful'? Can anyone there give me more
> > idea of it?
>
> I use the ARM 2.5 software on a daily basis with an EPI Jeeni via ethernet.
> My issues are as follows:
>
> * Asks "Do you want to start the debugger in remote debugging?" *EVERY* time
> the app starts (which is a big deal for me because each time I do a run I
> have to restart the app because there's no reset button and a reload won't
> always work)
>
If you're using ADW then there is check box in the debugger options that allows
you to switch of this behaviour. It will then immediately try to connect to your
remote target.
>
> * If I shift focus from the ARM debugger to another app while the debugger is
> running and try to come back to the ARM debugger, it won't respond to any
> keystrokes/mouse messages. I have to shift to another application's focus and
> then back to the ARM debugger to make it work again.
>
This I noticed too. After sometime I found that right-clicking on the taskbar bar
icon of ADW gets the focus back immediately.
>
> * No reset button on the debugger. Maybe this is my debugger hardware
> (Jeeni), but I'm having lots of trouble beliving that a basic feature like
> this was left out. What appears to be the reset button is greyed out on the
> debugger task bar. ;-(
>
> * If you reset your target out from underneath the application, the debugger
> will crash, which causes you to have to kill it via the task manager and
> restart the app
>
This unfortunately seems to be 'normal' for embedded debuggers. I've seen this
for the last 20 years.
Only in the last few months I've finally come across one that actually recognises
reset on the target. But then it is a > 10K$ ppc target/ICE.
>
> * Viewing of structural variables a bit kludgy. Maybe I'm spoiled by MSVC,
> but it seems as if the debugger already knows about the variable names and
> structures that it could figure out the values of the individual members
>
> * As you're stepping through code, the debugger "caches up" the code being
> debugged. That means if you're running out of RAM, and suddenly your referesh
> goes away or the RAM changes out from underneath the debugger, the debugger
> appears to be misexecuting the code. We chased this one for quite a while.
>
That is the tradeoff if you cache at all. The alternative would be not to cache
but load everything all the time over a rather slow jtag i/f.
>
> The ARM debugger (I'm running 2.50) seems like it'd be an excellent product,
> but the above shortcomings make it painful to deal with for me. And judging
> that the last release was November of 1998 and I've found no patches or
> updates for these bugs, I'm not hopeful that they will be fixed any time
> soon.
>
> -->Neil
Robin
Fred Viles
<3874FBBA...@intel.com>:
>David Liang wrote:
>
>> I am new to ARM world. Now we are on the stage of choosing a ARM
>> C compiler. Any suggestion will be very appreciated.
>>
>> Based on my prelimiary study, ARM SDT 2.5 seems to be a standard
>> compiler, how about it? I need some voice from real life ARM
>> developers. There are some complains about it from developers on
>> this newsgroup. They said it was 'painful'. Why is it 'painful'?
>> Can anyone there give me more idea of it?
>
>I use the ARM 2.5 software on a daily basis with an EPI Jeeni via
>ethernet. My issues are as follows:
>
>... <snip ARM debugger issues>
>
>* No reset button on the debugger. Maybe this is my debugger
>hardware (Jeeni), but I'm having lots of trouble beliving that a
>basic feature like this was left out. What appears to be the reset
>button is greyed out on the debugger task bar. ;-(
Unfortunately, yhe ARM debugger does not provide a UI for target
reset. The JEENI can control the target reset line if the SRST pin
is connected (and does so at startup time), but we didn't implement
user reset in the firmware since it would do no good without debugger
support. This can be especially annoying when the JEENI and target
system are in another room (or building).
It would be easy to add this to the JEENI if/when it will do some
good.
>The ARM debugger (I'm running 2.50) seems like it'd be an
>excellent product, but the above shortcomings make it painful to
>deal with for me. And judging that the last release was November
>of 1998 and I've found no patches or updates for these bugs, I'm
>not hopeful that they will be fixed any time soon.
Early reports are that the shiny new ARM debugger is much
better. Time will tell.
- Fred Viles
Grant Edwards
>>The ARM debugger (I'm running 2.50) seems like it'd be an
>>excellent product, but the above shortcomings make it painful to
>>deal with for me. And judging that the last release was November
>>of 1998 and I've found no patches or updates for these bugs, I'm
>>not hopeful that they will be fixed any time soon.
>
>Early reports are that the shiny new ARM debugger is much
>better. Time will tell.
Gdb doesn't seem to have any of these problems (except not
being able to reset the target due to hardware limitations).
And it's free
(libre _and_ gratis)
--
Grant Edwards grante Yow! By MEER biz doo
at SCHOIN...
visi.com
Keith Jasinski, Jr.
The gcc and gdb I am aware of are from Cygnus (now Red Hat). The only tools
that I can find from them that target ARM are $2500/seat (min 3 seats).
You say gdb is free, but how is that the case? Am I completely missing the
boat? They seem to have some cheap tools, but none that will target an ARM
processor.
We have been looking at ARM SDT 2.5, but I hear so many complaints about it.
We are planning to buy JEENIs from EPI for our debugger hardware.
Thanks in advance for your help!
--
Keith F. Jasinski, Jr.
kfja...@execpc.com
Grant Edwards <grant@nowhere.> wrote in message
news:slrn87c41m...@grante.comtrol.com...
Grant Edwards
>Perhaps you can answer a few questions for me...
>
>The gcc and gdb I am aware of are from Cygnus (now Red Hat).
>The only tools that I can find from them that target ARM are
>$2500/seat (min 3 seats).
That's if you want to buy pre-compiled, supported versions from Cygnus.
>You say gdb is free, but how is that the case? Am I completely
>missing the boat? They seem to have some cheap tools, but none
>that will target an ARM processor.
The standard gcc, binutils (assembler, linker), and gdb all
support the ARM (as well as a bunch of other processors). The
catch is that you have to either
1) Build the binaries from source specifying the host and
target you want.
or
2) Find somebody who has already build the binaries for the
host/target combination you want.
If you're willing to pay, Cygnus will build the binaries for
you and then support them. That's what the $2500 is for.
If you look around the web for a while, you can probably find
somebody who has made available binaries for the target/host
you want, but there are so many possible host/target
combinations that there's no single ftp site that has all of
them.
Building gcc/binutils/gdb from sources isn't all that hard, but
it does require a little effort -- mostly because the
instructions for building gcc assume that it's for a full-up
*nix, libc target environment. Building gcc for an embedded
target requires you to skip some stuff you don't need. Somebody
is working on updating the documentation for that.
--
Grant Edwards grante Yow! Do you think the
at "Monkees" should get gas on
visi.com odd or even days?
William Gatliff
>
> or
>
> 2) Find somebody who has already build the binaries for the host/target
> combination you want.
>
or,
3) find a consultant to help.
b.g.
--
William A. Gatliff
Senior Design Engineer
Komatsu Mining Systems
To teach is to learn.
Quality Quorum
Keith Jasinski, Jr. <jasi...@mortara.com> wrote:
>Perhaps you can answer a few questions for me...
>
>The gcc and gdb I am aware of are from Cygnus (now Red Hat). The only tools
>that I can find from them that target ARM are $2500/seat (min 3 seats).
>
>boat? They seem to have some cheap tools, but none that will target an ARM
>processor.
Cygnus/RedHat does not sell gdb/gcc it sells GNUPro Toolkit/Debugger
which are gcc/gdb based (and what you are paying for is mostly
support). Gdb/gcc are available through ftp (numerous sources) on CD
e.g http://sourcesware.cygnus.com - sells CD subscription for all GNU tools
and some other things for about $60/year. I suppose you would need
to newlib too. It is not that complicated, however, you have to
understand what are you doing.
>
>We have been looking at ARM SDT 2.5, but I hear so many complaints about it.
>We are planning to buy JEENIs from EPI for our debugger hardware.
>
>Thanks in advance for your help!
>
>--
>Keith F. Jasinski, Jr.
Thanks,
Aleksey
Keith Jasinski, Jr.
I gather from your posts that you are using gcc/gdb for use with ARM, so I
hope you can straighten me out here.
First a disclaimer - I am mainly a hardware guy. The software I write is
mainly limited to exercising that hardware, so I don't spend days and days
on software, so please forgive my ignorance.
Supporting info: Our company has been using a 68332 as it's processor
choice for as long as anyone can remember. We are now venturing into the
ARM family (specifically the ARM 720 for the first project) and need
development tools. We are currently demo-ing a JEENI from EPI Tools for the
hardware/PC interface. We are looking at ARM SDT 2.5 for tools (as well as
a couple others) all in the multi-K$$$ range. We really only need a
compiler/linker/etc (to generate a file that can be transfered to the
hardware) and a debugger to run with the JEENI. A software emulator is nice
and desirable, but if the software can be obtained for low-$$$, we can live
without it for now. Our environment is mainly Win95/98, although some
people here use NT.
What is it that people like Cygnus are charging big-$$$ to do with gcc/gdb?
You mention building binaries for our target environment, but Win95/98 can't
be that hard or unusual. Is the intelligence there to generate ARM code
(ie: can it do the job of turning a C or C++ program into machine op-codes
that the ARM will understand?
Basically, I could care less about support. Usually I find it overpriced
and underused. Support is nice for the first few days until you get
something working. Also, you mentioned (in a previous message) good free
support via web-site and newsgroup. Can you elaborate where those are?
Where do I start getting what I am looking for? I found www.gnu.org. The
Cygnus site someone mentioned in a previous message in this thread is not
valid.
Thanks for taking your valuable time to assist!
--
Keith F. Jasinski, Jr.
kfja...@execpc.com
Grant Edwards <grant@nowhere.> wrote in message
news:slrn87kgaf...@grante.comtrol.com...
> In article <9Oqe4.594$TK4.1...@homer.alpha.net>, Keith Jasinski, Jr.
wrote:
> >Perhaps you can answer a few questions for me...
> >
> >The gcc and gdb I am aware of are from Cygnus (now Red Hat).
> >The only tools that I can find from them that target ARM are
> >$2500/seat (min 3 seats).
>
> That's if you want to buy pre-compiled, supported versions from Cygnus.
>
> >You say gdb is free, but how is that the case? Am I completely
> >missing the boat? They seem to have some cheap tools, but none
> >that will target an ARM processor.
>
> The standard gcc, binutils (assembler, linker), and gdb all
> support the ARM (as well as a bunch of other processors). The
> catch is that you have to either
>
> 1) Build the binaries from source specifying the host and
> target you want.
>
> or
>
> 2) Find somebody who has already build the binaries for the
> host/target combination you want.
>
Grant Edwards
>We are currently demo-ing a JEENI from EPI Tools for the
>hardware/PC interface. We are looking at ARM SDT 2.5 for tools
>(as well as a couple others) all in the multi-K$$$ range. We
>really only need a compiler/linker/etc (to generate a file that
>can be transfered to the hardware) and a debugger to run with
>the JEENI. A software emulator is nice and desirable, but if
>the software can be obtained for low-$$$, we can live without
>it for now. Our environment is mainly Win95/98, although some
>people here use NT.
>What is it that people like Cygnus are charging big-$$$ to do
>with gcc/gdb?
They're charging for support and for the effort they put into
setting up and testing pre-compiled binaries in an
easy-to-install package.
>You mention building binaries for our target environment, but
>Win95/98 can't be that hard or unusual.
Your target is ARM. Your host is Win32. Getting the gnu stuff
built under Win32 is harder than building it under Unix. You
need to have the Cygwin package installed.
I would be happy to provide Linux(Intel) binaries, but that
doesn't do you much good. ;)
>Is the intelligence there to generate ARM code (ie: can it do
>the job of turning a C or C++ program into machine op-codes
>that the ARM will understand?
Yes. The standard gnu tools can generate and link ARM code
from C/C++. Gdb can talk to the EPI Jeeni via RS-232 or
Etherenet and provide source-level debugging. However, when
you build the compiler/linker toolset, only support for a single
target processor is compiled in. By default, the target
processor that is supported is figured out from the host: if
you're building gcc on a SPARC machine, it will be compiled so
that it generates SPARC code. However, you can tell the
configuration utility when you're building gcc that you want to
build a compiler that generates ARM code.
>Basically, I could care less about support. Usually I find it
>overpriced and underused. Support is nice for the first few
>days until you get something working. Also, you mentioned (in
>a previous message) good free support via web-site and
>newsgroup. Can you elaborate where those are?
There are mailing lists for cygwin, gcc, binutils, and gdb.
>Where do I start getting what I am looking for? I found
>www.gnu.org. The Cygnus site someone mentioned in a previous
>message in this thread is not valid.
I looked around on the Cygnus web/ftp site and didn't see
cross-compiler binaries available for download.
If you want to look, the Cygnus web site is:
<http://www.sourceware.cygnus.com/>
I know you can download the whole eCos-ARM devleopment toolset:
(eCOS RTOS sources along with pre-configured gcc, binutils, and
gdb sources). But I don't see pre-compiled binaries anywhere.
According to the web page below, if you get the complete Cygwin
distribution, it includes an ARM cross compiler.
<http://www.windowstechedge.com/wte/wte-1999-02/wte-02-oss.html>
If you want to try out the gnu tools, I guess you've got a
couple choices:
1) Install the cygwin package that is required for the gnu
stuff to run under Windows -- the Cygwin distribution
apparently includes an ARM cross-compiler (I don't know
if includes an ARM aware version of gdb.)
2) Try out the gnu tools under some sort of Unix (I'd
recommend Linux).
Being able to compile the tools yourself from source is always
a useful thing to be able to do, and I would exepct that it
will be easier to do under Linux, and in the long run you'll be
better off under Linux.
I've made some enhancements to the ARM-RDI code in Gdb (the
code that talks to the EPI Jeeni), so if you use gdb, you want
a recent copy (not more than a couple weeks old).
--
Grant Edwards grante Yow! I'm having a MID-WEEK
at CRISIS!
visi.com
Keith Jasinski, Jr.
Mr. Erasmus) have made what was as clear as mud, clear enough to read
through (not crystal, but well on the way).
Thanks for your assistance!
Keith
--
Keith F. Jasinski, Jr.
kfja...@execpc.com
Grant Edwards <grant@nowhere.> wrote in message
news:slrn87mrqh...@grante.comtrol.com...
William Gatliff
> There are mailing lists for cygwin, gcc, binutils, and gdb.
... and they're very good. Expect a useful answer in four hours or less, 24/7.
> 2) Try out the gnu tools under some sort of Unix (I'd recommend Linux).
Yes, start out with Linux if you can. As good as Cygwin is, the M$ platforms are
still not so good for running GNU stuff. Slow and unreliable.
In fact, I've had very little success building cross compilers under Cygwin.
It's slow (under Cygwin on my W98 K6II-333, it takes about six hours), and
Windoze usually dumps once or twice before I get finished.
Under Linux, it's another story entirely--- a flawless hour at most, and I can
still use the machine while the build is underway. :^)
Kai Ruottu
<jasi...@mortara.com> wrote:
>Perhaps you can answer a few questions for me...
>
>The gcc and gdb I am aware of are from Cygnus (now Red Hat). The only tools
>that I can find from them that target ARM are $2500/seat (min 3 seats).
>
>You say gdb is free, but how is that the case? Am I completely missing the
>boat? They seem to have some cheap tools, but none that will target an ARM
>processor.
Heard about EPOC ? The rival for WinCE in those Nokia, Ericsson,
Motorola, etc. 'handhelp computers', which one can use to make
cell-phone calls too... At least Nokia and Ericsson use ARM...
Ok, the toolset for EPOC is GNU-based and is freely downloadable
(EPOC isn't). Please see: 'www.epocworld.com'...
I think Atmel is going to release a GNU toolset for their AT91...
My old 'arm-coff' tools (egcs-1.1-based) have been available for
download over a year now... Please see:
http://www.saunalahti.fi/~ankosk2/embtools.htm
And check also Andy Hare's webpage:
http://www.hare.u-net.com/mainpage.htm
You will get just as much support as you are willing to pay,
starting with $20-50 for up-to-date-prebuilt ARM tools 'as is' in
diskettes or in a CDR...
Cheers, Kai
Andy Hare
Actually the web address given for my homepage is wrong, this will only get
the main pane and not the rest of the site. Please use
http://www.hare.u-net.com/home.htm.
I have pre-built versions of the ecos toolset and the insight debugger
running under CYGWIN b20.1 on an NT machine. I have used the same toolset
under windows 95 but sometimes the results are suspect. The debugger works
fine with the ATMEL EB01 development board. I am looking at adding the
toolset and insight to my download section of my web pages but they
currently weigh in at 20+MB and I only have 25 MB of web space. I need to
find a better method of compressing them than PKZIP. If you need any more
pointers then you are welcome to email me and I will try and help.
Andy Hare
Kai Ruottu <karu...@freenet.hut.fi> wrote in message
news:387d10df...@news.nettilinja.fi...
rsa...@my-deja.com
I've been using ARM 2.5, MICE 1.3 adn ADW and don't find extremely good
or excruciating bad. There are all the drawbacks people described here,
but after you get used to them you can live with them (there is no much
choice anyway!).
I found a way to reset target from the debugger (it is somewhere in the
MICE User Guide): 1. bring up "Debuger Variable" Window 2. Set
system_reset to one.
There are additional gripes about MICE (I recall Jeni relates too)
1. How hard is to have a pin on the JTAG box to generate a trigger to
the outsided world (scope, logic analizer) when breakpoint is hit? And
another way around: how hard to halt execution when input trigger is
generated from external device?
2. When I hit the breakpoint and do steping, I have manually to disable
interrupts (and do forget doing that every time). It would be a nice
option to have it configured through one of the debuger variables:
someting like - disable/enable interrupts during peek/poke operations.
ARM 2.5 graphic user interface is dismal. I use "armmake" and it works
fine with a generic UNIX-like make-file format.
I know that ARM was going to release new version of the tools based on
MetroWerks environment. Is there anybody who have insight in this
matter? MetroWerks was bought by Motorola, so I have doubghts how the
whole deal works.
-- Alex
Valentin Pepelea
Fred Viles <f...@do.whois.fv4.at.internic> wrote:
>
>Unfortunately, the ARM debugger does not provide a UI for target
>is connected (and does so at startup time), but we didn't implement
>user reset in the firmware since it would do no good without debugger
>support. This can be especially annoying when the JEENI and target
>system are in another room (or building).
>
>It would be easy to add this to the JEENI if/when it will do some
>good.
Excuse me, but doesn't the JEENI pretend to support the RDI protocol. And
does the latest GDB as well as Microtec's XRAY support that protocol too?
In fact, Microtec's documentation about XRAY/RDI specifically mentions JEENI
as being supported. Well, don't these two debuggers support remote resets?
I specifically know that XRAY does on other platforms.
>Early reports are that the shiny new ARM debugger is much
>better. Time will tell.
What is this debugger supposed to be called?
Valentin
--
"An operating system without virtual memory Valentin Pepelea
is an operating system without virtue." Embedded Systems Consultant
vale...@netcom.com
- Ancient Inca Proverb (808) 826-6059
Fred Viles
<86128u$tbj$1...@nntp4.atl.mindspring.net>:
>In article <8EB413F...@news2.brainstorm.net>,
>Fred Viles <f...@do.whois.fv4.at.internic> wrote:
>>
>>Unfortunately, the ARM debugger does not provide a UI for target
>>reset.
Another poster reported that ADW in SDT 2.50 does list a debugger
variable named "system_reset" when connected to a MultiICE, and that
setting this variable to 1 causes a target system reset.
This variable is not present when connecting to a target that uses
RemoteA, like JEENI, BlackICE, and Angel.
>> The JEENI can control the target reset line if the SRST
>>pin is connected (and does so at startup time), but we didn't
>>implement user reset in the firmware since it would do no good
>>without debugger support. This can be especially annoying when
>>the JEENI and target system are in another room (or building).
>>
>>It would be easy to add this to the JEENI if/when it will do some
>>good.
>
>Excuse me, but doesn't the JEENI pretend to support the RDI
>protocol.
JEENI supports RDI exactly as well as the ARM RDI 1.5.x DLL for
RemoteA does.
JEENI does not come with a JEENI-specific RDI DLL. It was designed
to be a drop-in replacement for the BlackICE, so it implements
RemoteA and uses the ARM RDI-to-RemoteA DLL. It is actually the
RemoteA protocol, not RDI, that lacks a target reset command.
> And does the latest GDB as well as Microtec's XRAY
>support that protocol too?
XRAY yes (I assume), GDB no. As I understand it, GDB does not
actually use RDI in the sense of connecting to a separate DLL or
shared lib provided by a third party. It actually talks RemoteA,
thanks to having incorporated the source code for a RemoteA version
of RDI (~1.0 or so).
> In fact, Microtec's documentation about
>XRAY/RDI specifically mentions JEENI as being supported. Well,
>don't these two debuggers support remote resets? I specifically
>know that XRAY does on other platforms.
I'm sure XRAY does, GDB I don't know about. But without some way to
pass the reset request to the probe, it's moot.
>>Early reports are that the shiny new ARM debugger is much
>>better. Time will tell.
>
>What is this debugger supposed to be called?
ARM eXtended Debugger (AXD). It's part of the new ADS 1.0 toolkit
that is intended to supercede SDT 2.50.
- Fred Viles (EPI)
Valentin Pepelea
Grant Edwards <grant@nowhere.> wrote:
>
>>Is the intelligence there to generate ARM code (ie: can it do
>>the job of turning a C or C++ program into machine op-codes
>>that the ARM will understand?
>
>Yes. The standard gnu tools can generate and link ARM code
>from C/C++. Gdb can talk to the EPI Jeeni via RS-232 or
>Etherenet and provide source-level debugging.
>I've made some enhancements to the ARM-RDI code in Gdb (the
>code that talks to the EPI Jeeni), so if you use gdb, you want
>a recent copy (not more than a couple weeks old).
This is too good to be true. I am looking for an inexpensive source-level
debugger/ICE that works with GCC object files (my open source kernel prefers
GCC), and this sounds so perfect. Please tell me the Insight interface works
dandy with this.
It would be nice if you could forward the latest GDB patches to Andy Hare
(andy at hare.u-net.com) who compiles the GCC ARM cross compilers for Win32.
Fred Viles should put up binaries for both Linux and Win32 up on the EPI web
site. I know I'll download them both right away, in addition to purchasing a
Jeeni.
> <http://www.windowstechedge.com/wte/wte-1999-02/wte-02-oss.html>
This host does not have a DNS entry.
Valentin
--
"An operating system without virtual memory Valentin Pepelea
is an operating system without virtue." Embedded Systems Consultant
vale...@netcom.com
- Ancient Inca Proverb (808) 822-0949
Grant Edwards
>>I've made some enhancements to the ARM-RDI code in Gdb (the
>>code that talks to the EPI Jeeni), so if you use gdb, you want
>>a recent copy (not more than a couple weeks old).
>
>This is too good to be true. I am looking for an inexpensive
>source-level debugger/ICE that works with GCC object files (my
>open source kernel prefers GCC), and this sounds so perfect.
>Please tell me the Insight interface works dandy with this.
Don't know. I use the DDD interface which seems to work fine.
I don't know of any reason why any other interface that can
work with a vanilla gdb would fail.
There is a trick you have to use when loading the file: you
load it the first time using the normal DDD file-menu method,
then you set the target and load it again via the gdb command
line. I think this would be easy to fix, but it hasn't
bothered me enough yet ;)
>It would be nice if you could forward the latest GDB patches to
>Andy Hare (andy at hare.u-net.com) who compiles the GCC ARM
>cross compilers for Win32.
The patches have all been incorporated into the gdb CVS. It
looks like the last two patches to the RDI target stuff
(connect via UDP, and stop target when gdb receives SIGINT)
were incorporated on 5 Jan 2000. If you grab a current CVS snapshot
it should all be there.
>Fred Viles should put up binaries for both Linux and Win32 up
>on the EPI web site. I know I'll download them both right away,
>in addition to purchasing a Jeeni.
--
Grant Edwards grante Yow! If this is the DATING
at GAME I want to know your
visi.com FAVORITE PLANET! Do I get
th' MICROWAVE MOPED?