RE: [ECOS] having ecos working with third-party development environment?

RE: [ECOS] having ecos working with third-party development environment?

[Cusson, Pascal]

I am using Insight (gdb) with the BDI2000 and it works pretty good. This
JTAG is also pretty cheap.

Pascal

-----Original Message-----
From: Scott Dattalo [mailto:scott@dattalo.com]
Sent: Monday, November 04, 2002 1:31 PM
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] having ecos working with third-party development
environment?


On Mon, 4 Nov 2002, Andrew Lunn wrote:

>                         gdb can talk to jtag if you want it to get
> closer to the hardware.

How?

The last I checked into it, gdb could not talk to the McCraigor Wiggler
JTAG module for the ARM7 core. Am I mistaken? (At the moment I use OCD
Commander under windows to down load code like RedBoot, but use gdb
[with
and without Insight] for debugging via a Serial port.)

Scott


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

RE: [ECOS] having ecos working with third-party development environment?

[Ryan Press]

> I am using Insight (gdb) with the BDI2000 and it works pretty good. This
> JTAG is also pretty cheap.
>
> Pascal
>

As am I.  The only problem I noticed was the lack of thread support.  Will
the "multi-ice-gdb-server" work with the BDI2000 to allow thread
debugging?  Anyone have any experience with this?

Ryan




-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] having ecos working with third-party development environment?

[Roland Caßebohm]

On Montag, 4. November 2002 19:31, Scott Dattalo wrote:
> On Mon, 4 Nov 2002, Andrew Lunn wrote:
> >                         gdb can talk to jtag if you want it to get
> > closer to the hardware.
>
> How?
>
> The last I checked into it, gdb could not talk to the McCraigor Wiggler
> JTAG module for the ARM7 core. Am I mistaken? (At the moment I use OCD
> Commander under windows to down load code like RedBoot, but use gdb [with
> and without Insight] for debugging via a Serial port.)
>
> Scott

http://www.ocdemon.com/OCDemonWindows.html

Here you can find a version of gdb which works with the wiggler, but it's only 
for windows too.

Roland

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] having ecos working with third-party development environment?

[Andy Hare]

OK guys,

McCraigor now have a gdb stub that runs on a win32 platform comminucates with both a parrallel port wiggler and GDB 
via TCP. I was writing such a beast and then someone pointed out to me that it had already been done. I have used it 
and once it is set up it works. I actually ran it on a win95 laptop and talked to it from a dual athlon machine running 
cygwin and Insight, was a bit slow but the network was only 10MB Coax. THe dual athon printer port does not function 
with the wiggler and I haven't tried the plug in card port I have, not enough hours in the day and a kitchen to build.


Andy Hare

www.ahare.btinternet.co.uk


11/5/2002 3:01:45 AM, Jonathan Larmour <jifl@eCosCentric.com> wrote:

>Scott Dattalo wrote:
>> On Mon, 4 Nov 2002, Andrew Lunn wrote:
>> 
>> 
>>>                        gdb can talk to jtag if you want it to get
>>>closer to the hardware.
>> 
>> 
>> How?
>> 
>> The last I checked into it, gdb could not talk to the McCraigor Wiggler
>> JTAG module for the ARM7 core. Am I mistaken? (At the moment I use OCD
>> Commander under windows to down load code like RedBoot, but use gdb [with
>> and without Insight] for debugging via a Serial port.)
>
>FSF GDB used to support the wiggler, but the support was removed because 
>it relied on a non-GPL DLL and the GDB maintainers decided that wasn't 
>Free enough.
>
>http://sources.redhat.com/ml/gdb/2001-10/msg00263.html
>
>Jifl
>-- 
>eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
>--[ "You can complain because roses have thorns, or you ]--
>--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine
>
>
>-- 
>Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
>and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>
>
Andy Hare

Development Manager
CDK Electronics Ltd
17-19 Buxton Road
Congleton
Cheshire
CW12 2DW
United Kingdom

Tel. 01260 296300




-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] having ecos working with third-party development environment?

[Jonathan Larmour]

Bart Veer wrote:
> 
>     Yin> Choice 2. Use ecos as library and have it built under GNU tools,
>     Yin>           write applications in 3rd-party IDE. 
> 
>     Yin>   The issue here seems to be that ecos uses GNU
>     Yin>   corss-compilers, and the application is developed using
>     Yin>   another set of cross- compilers/debugger.
> 
> Building the application code with non-GNU tools would also cause lots
> of problems, although perhaps not quite as bad as building eCos itself
> with those tools. 

If the non-GNU compiler is "link compatible" i.e. uses the same ABI, then 
it's less of an issue, as long as we're talking about plain C, not C++. 
Even then you must use only the GNU linker at the end.

Any semi-decent IDE should be able to call custom make rules to do builds. 
Even many that are normally intended to be used only with the vendor's 
compiler still allow that as you never know what some people want to do in 
their builds!

Jifl
-- 
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] having ecos working with third-party development environment?

[Jonathan Larmour]

Scott Dattalo wrote:
> On Mon, 4 Nov 2002, Andrew Lunn wrote:
> 
> 
>>                        gdb can talk to jtag if you want it to get
>>closer to the hardware.
> 
> 
> How?
> 
> The last I checked into it, gdb could not talk to the McCraigor Wiggler
> JTAG module for the ARM7 core. Am I mistaken? (At the moment I use OCD
> Commander under windows to down load code like RedBoot, but use gdb [with
> and without Insight] for debugging via a Serial port.)

FSF GDB used to support the wiggler, but the support was removed because 
it relied on a non-GPL DLL and the GDB maintainers decided that wasn't 
Free enough.

http://sources.redhat.com/ml/gdb/2001-10/msg00263.html

Jifl
-- 
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] having ecos working with third-party development environment?

[Bart Veer]

>>>>> "Yin" == Yin Bao <yin.bao@biometricsolutions.com> writes:

    Yin> I am new to ecos and just got the tools it needed and built the
    Yin> library successfully. I need some advice here: is it easy
    Yin> to have ecos working with a third-party development environment
    Yin> in general? Particularly, anybody has done that for Green Hill's
    Yin> MULTI 2000 (IDE for ARM)? My company is making its own hardware
    Yin> with ARM and considers this IDE being helpful in the long run,
    Yin> we are also considering using ecos as the RTOS since there
    Yin> is a port to the processor (Cirrus Logic 7312) from ecos.
    Yin> I can think of a few choices here and would like to get some
    Yin> recommendation/advice from ecos community:

    Yin> Choice 1. move ecos into the third-party IDE. 

    Yin>   This not only involves analyzing makefiles of ecos and
    Yin>   moving the sources into 3rd-party IDE; also involves using
    Yin>   3rd-party cross compiler. Is this doable? How tightly
    Yin>   coupled is ecos with the GNU based
    Yin>   cross-compilers/debuggers? Is it easy to just take ecos
    Yin>   source code into another IDE? Possibility of potential
    Yin>   problems? How much support there might be from ecos
    Yin>   community in that case?

Don't try this. Building eCos involves rather more than just existing
makefiles: it has its own configuration technology which, amongst
other things, generates makefiles appropriate to your configuration.
Trying to reproduce all this in some third party IDE would involve a
serious amount of work.

Also note that eCos is tied heavily to gcc/g++ compiler and linker
technology, and new dependencies on those tools may be added at any
time. Trying to use eCos with other tools would involve a lot of work
and ongoing maintenance.

    Yin> Choice 2. Use ecos as library and have it built under GNU tools,
    Yin>           write applications in 3rd-party IDE. 

    Yin>   The issue here seems to be that ecos uses GNU
    Yin>   corss-compilers, and the application is developed using
    Yin>   another set of cross- compilers/debugger.

Building the application code with non-GNU tools would also cause lots
of problems, although perhaps not quite as bad as building eCos itself
with those tools. Instead you should look at using the GNU tools from
inside the IDE of your choice. Some IDE's may be sufficiently flexible
to allow this, others will be tied to specific tools. If an IDE can be
configured to work with the GNU tools, that may prove viable for
developing the application code. eCos itself should still be built
using the eCos configuration tools, although you might be able to set
up custom build steps inside the IDE which can invoke the eCos tools.

Personally I am happy with my existing emacs-based development
environment, and have no wish to use a GUI-based IDE - in my
experience such environments just get in the way of doing the real
work. I suspect many eCos developers will have a similar attitude, so
you could expect only limited support from the eCos community.

Bart

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] having ecos working with third-party development environment?

[Scott Dattalo]

On Mon, 4 Nov 2002, Andrew Lunn wrote:

>                         gdb can talk to jtag if you want it to get
> closer to the hardware.

How?

The last I checked into it, gdb could not talk to the McCraigor Wiggler
JTAG module for the ARM7 core. Am I mistaken? (At the moment I use OCD
Commander under windows to down load code like RedBoot, but use gdb [with
and without Insight] for debugging via a Serial port.)

Scott


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] having ecos working with third-party development environment?

[Andrew Lunn]

What's your definition of an IDE? To me Unix is an IDE? All commands
talk to each other using pipes. Its not a GUI, but who actually wants
a GUI? I don't. Some people claim that emacs is an IDE. You can edit
text, compile from it, goto next error, run greps, use gdb from within
it, etc..... 

I guess the important question is, what do you gain from an IDE which
you don't already have?

eCos uses some gcc extensions. This makes it hard to use anything else
than gcc. Constructor ordering is one of them. This makes 1) a lot of
work. You have to find if its possible to do this in the IDE native
tool chain. 2) is a possibility, if you can make your IDE use gcc. A
lot depends on what your IDE is, but you should be able to tell it to
use a different tool chain than the default one. 

I've always used 3. gdb does all i want. It does more, but i've not
learnt everything thats in the manual. If you want a user unfriendly
GUI use Insight or DDD etc. gdb can talk to jtag if you want it to get
closer to the hardware.

       Andrew

> Choice 1. move ecos into the third-party IDE. 
> 
>   This not only involves analyzing makefiles of ecos and moving
>   the sources into 3rd-party IDE; also involves using 3rd-party
>   cross compiler. Is this doable? How tightly coupled is ecos
>   with the GNU based cross-compilers/debuggers? Is it easy to just
>   take ecos source code into another IDE? Possibility of potential
>   problems? How much support there might be from ecos community
>   in that case?
> 
> Choice 2. Use ecos as library and have it built under GNU tools,
>           write applications in 3rd-party IDE. 
> 
>   The issue here seems to be that ecos uses GNU corss-compilers,
>   and the application is developed using another set of cross-
>   compilers/debugger.   
>   
> Choice 3. Write the application in ecos environment (without 
>   3rd-party IDE at all)
> 
>   My question in general here is that how powerful is Gnu GDB
>   in the areas of debugging ARM/home-grown hardware/software, etc.?
> 
> I know these are generic questions however any recommendation/advice
> of what/what not to do is appreiciated, plus any sharing of 
> experiences that you might have had in similar situations.
> Thanks in advance.

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

[ECOS] having ecos working with third-party development environment?

[Yin Bao]

I am new to ecos and just got the tools it needed and built the
library successfully. I need some advice here: is it easy
to have ecos working with a third-party development environment
in general? Particularly, anybody has done that for Green Hill's
MULTI 2000 (IDE for ARM)? My company is making its own hardware
with ARM and considers this IDE being helpful in the long run,
we are also considering using ecos as the RTOS since there
is a port to the processor (Cirrus Logic 7312) from ecos.
I can think of a few choices here and would like to get some
recommendation/advice from ecos community:

Choice 1. move ecos into the third-party IDE. 

  This not only involves analyzing makefiles of ecos and moving
  the sources into 3rd-party IDE; also involves using 3rd-party
  cross compiler. Is this doable? How tightly coupled is ecos
  with the GNU based cross-compilers/debuggers? Is it easy to just
  take ecos source code into another IDE? Possibility of potential
  problems? How much support there might be from ecos community
  in that case?

Choice 2. Use ecos as library and have it built under GNU tools,
          write applications in 3rd-party IDE. 

  The issue here seems to be that ecos uses GNU corss-compilers,
  and the application is developed using another set of cross-
  compilers/debugger.   
  
Choice 3. Write the application in ecos environment (without 
  3rd-party IDE at all)

  My question in general here is that how powerful is Gnu GDB
  in the areas of debugging ARM/home-grown hardware/software, etc.?

I know these are generic questions however any recommendation/advice
of what/what not to do is appreiciated, plus any sharing of 
experiences that you might have had in similar situations.
Thanks in advance.

Yin



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss