[ECOS] eCos Configuration Tool

[ECOS] eCos Configuration Tool

[Emilio Monti]

Is there any plan to convert the "eCos Configuration Tool" in Java ?
It would also be usefull to better integrate the eCos configuration in Eclipse.

There are plenty of "open source" projects for "Parser Generator" and
"Code Generator" in Java that could form a good basis for a project
like that.

It could be an advantage also for the GUI.
Java mantains portability, like wxWindows, but enances graphics.

For the manage of makefiles and cygwin/unix tools there is a good code
basis in the eclipse CDT plugins.

If there's any project like that I would be happy to help.

Best regards,
Emilio Monti.

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

Re: [ECOS] eCos Configuration Tool

[Andrew Lunn]

On Sun, Sep 18, 2005 at 07:59:33PM +0200, Emilio Monti wrote:
> Is there any plan to convert the "eCos Configuration Tool" in Java ?
> It would also be usefull to better integrate the eCos configuration in Eclipse.
> 
> There are plenty of "open source" projects for "Parser Generator" and
> "Code Generator" in Java that could form a good basis for a project
> like that.
> 
> It could be an advantage also for the GUI.
> Java mantains portability, like wxWindows, but enances graphics.
> 
> For the manage of makefiles and cygwin/unix tools there is a good code
> basis in the eclipse CDT plugins.
> 
> If there's any project like that I would be happy to help.

There is no project that i know of.

My impression is that none of the maintainers actually use the
configtool. At least i don't use it, and always give debug
instructions using ecosconfig. The other maintainers are also mostly
unix people who like CLI programs and so use ecosconfig all the time.

I think the configtool is more to keep the commercial clients happy
where the management people have a percieved need for a "friendly GUI"
when they buy eCos from the companies that give commercial support. I
don't remember anybody actually contributing patches for the
configtool, so from an open source perspective, the configtool is
dead. The RTOS is what people are interested in, not the tools needed
to configure it.

I suspect that a java version would similar be dead unless it got a
maintainer who had a passion to write and maintain it and i also
suspect there would be little help from the eCos community. However i
could be wrong, so don't let me put you off from trying....

        Andrew

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

Re: [ECOS] eCos Configuration Tool

[Emilio Monti]

Thank you for the information.
First I will give a closer look to ecosconfig.
Emilio


2005/9/18, Andrew Lunn <andrew@lunn.ch>:
> On Sun, Sep 18, 2005 at 07:59:33PM +0200, Emilio Monti wrote:
> > Is there any plan to convert the "eCos Configuration Tool" in Java ?
> > It would also be usefull to better integrate the eCos configuration in Eclipse.
> >
> > There are plenty of "open source" projects for "Parser Generator" and
> > "Code Generator" in Java that could form a good basis for a project
> > like that.
> >
> > It could be an advantage also for the GUI.
> > Java mantains portability, like wxWindows, but enances graphics.
> >
> > For the manage of makefiles and cygwin/unix tools there is a good code
> > basis in the eclipse CDT plugins.
> >
> > If there's any project like that I would be happy to help.
> 
> There is no project that i know of.
> 
> My impression is that none of the maintainers actually use the
> configtool. At least i don't use it, and always give debug
> instructions using ecosconfig. The other maintainers are also mostly
> unix people who like CLI programs and so use ecosconfig all the time.
> 
> I think the configtool is more to keep the commercial clients happy
> where the management people have a percieved need for a "friendly GUI"
> when they buy eCos from the companies that give commercial support. I
> don't remember anybody actually contributing patches for the
> configtool, so from an open source perspective, the configtool is
> dead. The RTOS is what people are interested in, not the tools needed
> to configure it.
> 
> I suspect that a java version would similar be dead unless it got a
> maintainer who had a passion to write and maintain it and i also
> suspect there would be little help from the eCos community. However i
> could be wrong, so don't let me put you off from trying....
> 
>         Andrew
>

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

RE: [ECOS] eCos Configuration Tool

[Andrew Voelkel]

I guess that explains why some of the buggy GUI behavior in configtool
hasn't been attended to. It is a shame, because the graphic tool is good for
getting one's bearings and visualizing the hierarchy.

I guess it is time to learn how to use ecosconfig.

- Andy

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Andrew Lunn
Sent: Sunday, September 18, 2005 11:43 AM
To: Emilio Monti
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] eCos Configuration Tool

On Sun, Sep 18, 2005 at 07:59:33PM +0200, Emilio Monti wrote:
> Is there any plan to convert the "eCos Configuration Tool" in Java ?
> It would also be usefull to better integrate the eCos configuration in
Eclipse.
> 
> There are plenty of "open source" projects for "Parser Generator" and
> "Code Generator" in Java that could form a good basis for a project
> like that.
> 
> It could be an advantage also for the GUI.
> Java mantains portability, like wxWindows, but enances graphics.
> 
> For the manage of makefiles and cygwin/unix tools there is a good code
> basis in the eclipse CDT plugins.
> 
> If there's any project like that I would be happy to help.

There is no project that i know of.

My impression is that none of the maintainers actually use the
configtool. At least i don't use it, and always give debug
instructions using ecosconfig. The other maintainers are also mostly
unix people who like CLI programs and so use ecosconfig all the time.

I think the configtool is more to keep the commercial clients happy
where the management people have a percieved need for a "friendly GUI"
when they buy eCos from the companies that give commercial support. I
don't remember anybody actually contributing patches for the
configtool, so from an open source perspective, the configtool is
dead. The RTOS is what people are interested in, not the tools needed
to configure it.

I suspect that a java version would similar be dead unless it got a
maintainer who had a passion to write and maintain it and i also
suspect there would be little help from the eCos community. However i
could be wrong, so don't let me put you off from trying....

        Andrew

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



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

Re: [ECOS] eCos Configuration Tool

[Dirk Husemann]

[-- Attachment #1: Type: text/plain, Size: 3075 bytes --]

Andrew Lunn wrote:

>On Sun, Sep 18, 2005 at 07:59:33PM +0200, Emilio Monti wrote:
>  
>
>>Is there any plan to convert the "eCos Configuration Tool" in Java ?
>>It would also be usefull to better integrate the eCos configuration in Eclipse.
>>
>>There are plenty of "open source" projects for "Parser Generator" and
>>"Code Generator" in Java that could form a good basis for a project
>>like that.
>>
>>It could be an advantage also for the GUI.
>>Java mantains portability, like wxWindows, but enances graphics.
>>
>>For the manage of makefiles and cygwin/unix tools there is a good code
>>basis in the eclipse CDT plugins.
>>
>>If there's any project like that I would be happy to help.
>>    
>>
>
>There is no project that i know of.
>
>My impression is that none of the maintainers actually use the
>configtool. At least i don't use it, and always give debug
>instructions using ecosconfig. The other maintainers are also mostly
>unix people who like CLI programs and so use ecosconfig all the time.
>
>I think the configtool is more to keep the commercial clients happy
>where the management people have a percieved need for a "friendly GUI"
>when they buy eCos from the companies that give commercial support. I
>don't remember anybody actually contributing patches for the
>configtool, so from an open source perspective, the configtool is
>dead. The RTOS is what people are interested in, not the tools needed
>to configure it.
>  
>
actually, no. in my experience, both tools and embeddedOS are what ppl 
are interested in. some developers are more comfortable with 
commandline, some like GUI, some use both (i find it easier to find 
things/options in configtool).

what has been annoying is that configtool and ecosconfig don't have the 
same view of the build tree: ecosconfig assumes to already live in a 
particulare subdirectory, configtool assumes it has to create the build 
and the install directories first. it would be nice to have *one* view 
of the world...

also, while i'm at it :-) both configtool and ecosconfig copy header 
files into the install tree, it would be extremely helpful if we could 
have an option to symlink instead --- why? well, debugging with GDB 
within emacs: gdb ends up using the correct .c files, but unfortunately 
uses the copied .h files, nasty if you spot a bug in the .h file, fix it 
and then are surprised that the bug fix disappeared (because it was made 
to a header file in the install tree and not in the originating ecos tree).

    just my 2 cents,
    dirk


-- 
Dr Dirk Husemann, Pervasive Computing, IBM Research, Zurich Research Lab
	hud@zurich.ibm.com --- http://www.zurich.ibm.com/~hud/
       PGP key: http://www.zurich.ibm.com/~hud/contact/PGP
  PGP Fingerprint: 983C 48E7 0A78 A313 401C  C4AD 3C0A 278E 6431 A149
	     Email only authentic if signed with PGP key.

Appended to this email is an electronic signature attachment. You can
ignore it if your email program does not know how to verify such a
signature. If you'd like to learn more about this topic, www.gnupg.org
is a good starting point.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [ECOS] eCos Configuration Tool

[Andrew Lunn]

> >I think the configtool is more to keep the commercial clients happy
> >where the management people have a percieved need for a "friendly GUI"
> >when they buy eCos from the companies that give commercial support. I
> >don't remember anybody actually contributing patches for the
> >configtool, so from an open source perspective, the configtool is
> >dead. The RTOS is what people are interested in, not the tools needed
> >to configure it.
> > 
> >
> actually, no. in my experience, both tools and embeddedOS are what ppl 
> are interested in. some developers are more comfortable with 
> commandline, some like GUI, some use both (i find it easier to find 
> things/options in configtool).

I worded that badly. What i ment was developers are interested in
developing the RTOS further. Lots of people contribute patches for the
RTOS. Nobody seems interesting in developing the tools further. Nobody
contributes patchs for the tools.

> also, while i'm at it :-) both configtool and ecosconfig copy header 
> files into the install tree, it would be extremely helpful if we could 
> have an option to symlink instead --- why? well, debugging with GDB 
> within emacs: gdb ends up using the correct .c files, but unfortunately 
> uses the copied .h files, nasty if you spot a bug in the .h file, fix it 
> and then are surprised that the bug fix disappeared (because it was made 
> to a header file in the install tree and not in the originating ecos tree).

I've fallen faul of the same problem once or twice until i got used to
it. Well this is a good chance to show that people are interested in
to the tools. Please contribute a patch to add this feature to the
tools :-)
        
        Andrew

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

[ECOS] Re: eCos Configuration Tool

[John Dallaway]

Andrew Lunn wrote:

> On Sun, Sep 18, 2005 at 07:59:33PM +0200, Emilio Monti wrote:
>
>> Is there any plan to convert the "eCos Configuration Tool" in Java ?
>> It would also be usefull to better integrate the eCos configuration
>> in Eclipse.

There are no such plans at present. While I would like to see the eCos
Configuration Tool more closely integrated into the Eclipse workbench,
re-implementation of the host tools has never been high on the
maintainers' list of priorities.

> My impression is that none of the maintainers actually use the
> configtool. At least i don't use it, and always give debug
> instructions using ecosconfig. The other maintainers are also mostly
> unix people who like CLI programs and so use ecosconfig all the time.

I, for one, use the eCos Configuration Tool. I find that the GUI offers
a better overview of the configuration space. Many of my colleagues do
prefer ecosconfig. It really is a matter of personal preference.

John Dallaway
eCosCentric Limited

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

[ECOS] eCos Configuration Tool

[diem.b.dang]

Hi All;

     I'm trying to do the memory test on the board with 256k SRAM; the code is
very simple as start a location write to it and read right out by printf:

....
#define START_RAM_ADD  ((volatile U8 *) 0x00000000)
....
U8 *ram_add;
.....
 ram_add=START_RAM_ADD;   /* assign the pointer to the beginning of add */

 for(n=0;n<1000;n++)  {
       *ram_add = 0xAD;                      /* Write to the address a hex value
 AD */
       printf ("%d RAM address %08X %02X \n", n, ram_add, *ram_add);
       ram_add++;                                  /* Increase the address
location */
}

The problem is that the output is always stop at 0x340 sometime at 0x345 (around
800 some bytes...)

1/ Is the problem come from my eCos configuration setup limit the amonut of RAM;
if yes, where do I change in the configuration; or what item in configuratool
should be change.

2/ Does eCos has ready code to run for RAM test, If yes please show where can I
get the code.

Any Assistance is Very Appreciated;
Diem

Re: [ECOS] eCos Configuration Tool

[Jonathan Larmour]

diem.b.dang@delphiauto.com wrote:
> 
> Hi All;
> 
>      I'm trying to do the memory test on the board with 256k SRAM; the code is
> very simple as start a location write to it and read right out by printf:
> 
> ....
> #define START_RAM_ADD  ((volatile U8 *) 0x00000000)
> ....
> U8 *ram_add;
> .....
>  ram_add=START_RAM_ADD;   /* assign the pointer to the beginning of add */
> 
>  for(n=0;n<1000;n++)  {
>        *ram_add = 0xAD;                      /* Write to the address a hex value
>  AD */
>        printf ("%d RAM address %08X %02X \n", n, ram_add, *ram_add);
>        ram_add++;                                  /* Increase the address
> location */
> }
> 
> The problem is that the output is always stop at 0x340 sometime at 0x345 (around
> 800 some bytes...)

At a guess because that memory is being used by eCos for something else, so
writing to it will kill something. You don't say what platform this is so I
can't tell for sure.
 
> 1/ Is the problem come from my eCos configuration setup limit the amonut of RAM;
> if yes, where do I change in the configuration; or what item in configuratool
> should be change.

The MLT has the memory layout.
 
> 2/ Does eCos has ready code to run for RAM test, If yes please show where can I
> get the code.

In CVS there is a heaptest test in the memory allocation package. That's
the closest. But it can't test memory in use by the rest of eCos, only the
heap.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions    http://www.redhat-techworld.com/