This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
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