This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: VxWorks type embedded "shell" for eCos


On Fri, 06 Feb 2004 12:11:40 +0000
Kelvin Lawson <klawson@ad-holdings.co.uk> wrote:

>
> Is there a way to create a new thread running a specified function from 
> GDB ? I find this very useful and don't think GDB supports it. It's very 
> convenient for running quick tests - you can run a test function with 
> different arguments without going through a rebuild and redownload cycle.
> 

All of this, is just a matter of habits, or way-of-life. If I understand
your point of view spawning a new thread is great just because it enable
you to reach new updated code in a somewhat manageable context !

I do not play with calling complex function from gdb, but there is no
more complexity in creating a new thread from helper functions than
any other functions. It's just a matter of few lines of code.

What makes your experience more favorable is to not redownload the full
application (1Mo) over a 38400baud line ?

I worked last year on eCos with a fellow, someone who previously worked with VxWorks. And that was the same old pros and cons. There is really
a rich ground to forge some ultra-expensive architecture. But we managed our goals without all of this ! The winning key-point was to
use the eCos-synthetic when it made sens (plus some tools/patches and
gdb scripts in that application-aware environment).

May be the Lua script approach is useful. But I've no experiences in
the area.

> 
> It's just my personal preference. I found the VxWorks shell made me more 
> productive and enabled me to quickly run a bunch of tests on a target. 
> Obviously these are not real-world tests and you wouldn't put something 
> out the door having just run it from a shell internally. But it has a 
> time and a place, and during development I found it made my life easier.
> 

Scripting is likely to be what you have ever dream of, without putting
a name on it. With the current releases, you can either
  . script your eCos (Lua, your own engine ...)
  . script GDB (small memory footprint)

> I'm not sure what would be needed on the host-side. When I did a similar 
>   shell for Nucleus, I just downloaded a COFF file to the target 
> containing the symbol information, and extracted the symbols at runtime 
> from the image in RAM. It takes a fair amount of memory so it's not 
> suitable for everyone.

A fair amount of memory.
I tried to play with ported dynamic loader (PIC-only) on the eCos, 2-3 years ago. It seemed to work, and porting was not so difficult. But we didn't keep the code up-to-date every-platform-aware, since this is really a fair amount of work.

With the experience back, I would rather experiment another approach
if it were absolutely requested : By-part linking provided with GNU LD
(without garbage-collect and forcing undefined "syscalls") should be
sufficient to provide you with a "dangerous" but more powerful environment. Think of it like this : burn a fair amount of unchanged
code in FLASH, and HAL_BREAKPOINT in order to load the second part of
a RAM link (under dev. code).

The nice is that the complex part of the work is handled in GDB and LD,
plus some consistency build management or other kind of scripts.

> 
> I agree that it shouldn't impose dependencies etc in the rest of the 
> system but I don't think it needs to. Depending on the feature-set I 
> think it could be well self-contained.
> 
> Cheers,
> Kelvin.

If your job is to spent time on the infrastructure, great ! What a lucky job. And of course the community will be forever grateful for contributing back. Otherwise take a look on same starting ideas above.

If I got some agreements from the boss, I may contribute back very old pieces of code, but do not me ask for them now, I do not have them.

--
 
Eric DONNAT

Silicomp Research Institute
http://www.ri.silicomp.com

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]