On 09 Aug 2006 21:05:33 +0100, Bart Veer <[EMAIL PROTECTED]> wrote:
>>>>> "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
I'm not convinced that it is better to solve this in the TCL domain. There are very few engineers who can or want to use TCL(I certainly try to hide those skills so I don't get that sort of work :-) as opposed to other solution domains where static cdl files can be generated. I'm not sure why it is important that a repository is write only. It's better to have this problem solved in a slightly sub-optimal programming language where multiple engineers can actually touch the code. ecos.ecc is generated, modified and still part of my source code/goes into source control, so why not a dynamic HAL as well? Especially since a generated HAL can be part of a seperate eCos repository... (The fact that ECOS_REPOSITORY can support multiple repositories surprised me and has me hatching evil plans as I write :-) -- Ø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
