>>>>> "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.
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.
Architectural, processor and variant HALs obviously belong in the eCos
repository, they can be re-used across multiple platforms.
Typically there will be information in the platform HAL which other
packages will want to know at compile-time. For example the cpu speed
on a particular board is typically a characteristic of the platform
HAL but that information may be needed in various places, e.g. in
serial drivers when converting baud rates to register values. If you
make the platform HAL part of the application then the only way eCos
packages can get hold of that kind of information is at link-time via
variables or functions. That has code-size and performance penalties.
You also need to consider what happens from a maintainer's
perspective:
1) how do you build and run the tests for a given platform if the
platform details are held in application space?
2) similarly how do you build RedBoot (assuming RedBoot is appropriate
for the target hardware)?
3) how do you make coherent releases for a given platform, e.g. a
standard evaluation board?
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.
Bart
--
Bart Veer eCos Configuration Architect
http://www.ecoscentric.com/ The eCos and RedBoot experts
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
