This is the mail archive of the ecos-discuss@sourceware.org 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: NIOS2 toolchain build failure under Cygwin


On 09 Aug 2006 16:20:23 +0100, Bart Veer <bartv@ecoscentric.com> wrote:
>>>>> "Oyvind" == =?ISO-8859-1?Q?=D8yvind Harboe?= <ISO-8859-1> writes:

<snip>

    >> Building eCos for NIOS2 is the biggest mess I've ever seen: A
    >> Shell script wrapper for a Java program that generates a CDL
    >> file that generates a shell script that generates a Perl script
    >> that calls a Java program that generates include files, etc.
    >> etc.
    >>
    >> What a pile.

Oyvind> I don't know why Altera thinks it needs to be that way.

    Oyvind> Though I can see how a soft-CPU with a dynamic number of
    Oyvind> peripherals would be a poor impeadance match with eCos
    Oyvind> static cdl files.

According to the design, CDL files do not have to be static. CDL is
embedded in a general-purpose scripting language, Tcl. Conceptually
that gives it the flexibility to adapt to changing hardware, including
reconfigurable systems. The problems are:

  1) the CDL implementation is still incomplete, for a variety of
     reasons I do not intend to go into here.

  2) not all the concepts behind CDL are widely understood, leading to
     flawed approaches like generating static CDL files.

I knew that, but forgot while I wrote what I did. I can see how a non-TCL guru would want to generate CDL instead of understanding the finer point of TCL+CDL :-)

Is there a fundamental reason why CDL should not be generated?

Java + Eclipse beats the crap out of TCL + vi when in terms of a
development environment :-)

    Oyvind> I never quite understood why eCos considers a specific HAL
    Oyvind> part of eCos. I always viewed the HAL as part of the
    Oyvind> application. Although final PCB's might strongly resemble
    Oyvind> a particular evaluation board, I wouldn't expect it to be
    Oyvind> exactly like the evaluation board in the general case.
    Oyvind> Never happened to me anyway. The stuff that can be shared
    Oyvind> between HALs and that does not change between HALs seems
    Oyvind> to belong(as in making the whole shebang more easily
    Oyvind> maintainable) in eCos.

I assume you are referring here specifically to platform HALs.

More specifically a HAL for a customer specific PCB. Those HALs belongs in the application space.

Evaluation boards, quite possibly in eCos.

Architectural, processor and variant HALs obviously belong in the eCos
repository, they can be re-used across multiple platforms.

Makes sense.


Having platform HALs makes some things a lot easier, even if at times
it may make life a bit more difficult for application developers
porting to custom hardware.

I would consider custom hardware the common case and not the exception for deeply embedded applications.

--
Øyvind Harboe
http://www.zylin.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]