* [ECOS] Re: eCos with non-GNU compiler
[not found] <F12384A3C489D411944100B0D07C673A21D1@NS1-2>
@ 2000-09-15 9:11 ` Cedric Berger
2000-09-15 9:34 ` Greg Shubin
0 siblings, 1 reply; 3+ messages in thread
From: Cedric Berger @ 2000-09-15 9:11 UTC (permalink / raw)
To: James Dabbs; +Cc: cedric, ecos-discuss
James Dabbs wrote:
> >But don't bother porting GDB and it's related stubs, MULTI is far,
> >far better as a debugging environment.
>
> So would this require splicing the Green Hills debugger into eCos?
If your uC has a JTAG interface, just use the $100 wiggler JTAG - parallel
port interface and you're done.
For non-JTAG processors, I don't know, but in a sense a RTOS is nothing
more than any other program and could probably be debugged with whatever
mechanism is available with MULTI.
>
> This is an interesting exercise. When we add up the royalties for VxWorks,
> or the "Project/CPU/Developer" charges for ThreadX, Nucleus, or smx, we
> really have to ask ourselves if it isn't cheaper to put a guy on getting
> eCos or RTEMS running. Even through neither eCos nor RTEMS supports M-Core
> and neither runs in our development environment, this is not a clear call.
Yes, I don't really know why theses guys like VxWorks charge so much for
a 20-year old technology. Their tools are great, but their licensing scheme is
insane. Long-life to open-source projects in this area...
Cedric
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [ECOS] Re: eCos with non-GNU compiler
2000-09-15 9:11 ` [ECOS] Re: eCos with non-GNU compiler Cedric Berger
@ 2000-09-15 9:34 ` Greg Shubin
0 siblings, 0 replies; 3+ messages in thread
From: Greg Shubin @ 2000-09-15 9:34 UTC (permalink / raw)
To: egcs; +Cc: ecos-discuss
Cedric Berger wrote:
> James Dabbs wrote:
>
> > >But don't bother porting GDB and it's related stubs, MULTI is far,
> > >far better as a debugging environment.
> >
> > So would this require splicing the Green Hills debugger into eCos?
>
> If your uC has a JTAG interface, just use the $100 wiggler JTAG - parallel
> port interface and you're done.
> For non-JTAG processors, I don't know, but in a sense a RTOS is nothing
> more than any other program and could probably be debugged with whatever
> mechanism is available with MULTI.
Except most other programs don't muck with the stack pointer and do context
switching. I don't know anything about MULTI, but at least GDB/Insight support
thread debugging.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [ECOS] Re: eCos with non-GNU compiler
@ 2000-09-14 19:17 Cedric Berger
0 siblings, 0 replies; 3+ messages in thread
From: Cedric Berger @ 2000-09-14 19:17 UTC (permalink / raw)
To: ecos-discuss
I'm using Green Hills MULTI right now.
I've never tried do compile eCos for the compiler has a "GNU-Compatible"
mode which emulates many of the common GCC extensions, so I'm pretty
sure that it can works without too much effort.
But don't bother porting GDB and it's related stubs, MULTI is far,
far better as a debugging environment.
For the standard libraries, you can choose between using eCos libraries
or customize the Green Hills libraries.
Cedric
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2000-09-15 9:34 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <F12384A3C489D411944100B0D07C673A21D1@NS1-2>
2000-09-15 9:11 ` [ECOS] Re: eCos with non-GNU compiler Cedric Berger
2000-09-15 9:34 ` Greg Shubin
2000-09-14 19:17 Cedric Berger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).