>>>>> "Oyvind" == =?ISO-8859-1?Q?=D8yvind Harboe?= <ISO-8859-1> writes:
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 knew that, but forgot while I wrote what I did. I can
Oyvind> see how a non-TCL guru would want to generate CDL instead
Oyvind> of understanding the finer point of TCL+CDL :-)
Oyvind> Is there a fundamental reason why CDL should not be
Oyvind> generated?
With configurable h/w there are two main ways of handling things:
1) have a separate tool which takes the h/w definition file and
generates static CDL, the HAL header files defining things like I/O
addresses and interrupt vectors, etc. Then run up ecosconfig or the
graphical configuration tool, as desired.
2) have an intelligent CDL script which processes the h/w definition
file, either directly or by invoking a separate utility and reading
its output, and generates the appropriate configuration options in
memory. In addition have a define_proc which will create the HAL
header files etc.
Approach (2) involves one less step for the user so there is less to
go wrong. It also maintains the idea of a read-only component
repository as far as application developers are concerned. The
generated CDL options only live in memory, there is no need to write
them to a file. The generated HAL headers live in the build tree
alongside other generated headers like <pkgconf/system.h>. So from the
eCos perspective everything pretty much works the same as with more
traditional h/w targets.
Writing the intelligent CDL script is obviously going to be more
challenging. There is also the problem of telling that script where
the h/w definition file is located, but that should not be a major
obstacle.
So although there is nothing to stop people from generating static CDL
scripts, I do consider it to be a sub-optimal solution. If a CDL/Tcl
guru is required there is always http://www.ecoscentric.com/develop.shtml