From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24145 invoked by alias); 14 Aug 2006 13:28:34 -0000 Received: (qmail 24137 invoked by uid 22791); 14 Aug 2006 13:28:33 -0000 X-Spam-Check-By: sourceware.org Received: from snape.ecoscentric.com (HELO snape.ecoscentric.com) (212.13.207.199) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 14 Aug 2006 14:28:26 +0100 Received: from localhost (localhost [127.0.0.1]) by snape.ecoscentric.com (Postfix) with ESMTP id 1C1302C065; Mon, 14 Aug 2006 14:28:24 +0100 (BST) Received: from snape.ecoscentric.com ([127.0.0.1]) by localhost (snape.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWk-qE+Xwq7G; Mon, 14 Aug 2006 14:28:21 +0100 (BST) Received: from delenn.bartv.net (snape.ecoscentric.com [212.13.207.199]) by snape.ecoscentric.com (Postfix) with ESMTP id 720502C01F; Mon, 14 Aug 2006 14:28:21 +0100 (BST) Date: Mon, 14 Aug 2006 13:28:00 -0000 Message-Id: To: oyvind.harboe@zylin.com CC: ecos-discuss@ecos.sourceware.org In-reply-to: (oyvind.harboe@zylin.com) From: Bart Veer References: Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Are the HALs in the eCos repository meant for deployment? X-SW-Source: 2006-08/txt/msg00145.txt.bz2 >>>>> "Oyvind" == =?ISO-8859-1?Q?=D8yvind Harboe?= writes: Oyvind> Are the HALs in the eCos repository meant for deployment? Oyvind> I would expect the average PCB to be somewhat/quite Oyvind> similar to an exisiting development board. I would *not* Oyvind> expect that the average product(hardware/software) would Oyvind> use some HAL completely unmodified. There is a range of scenarios. Some evaluation boards may provide all the peripherals needed for the target application, quite possibly with a few too spare. For smallish volumes it will be a lot more cost-efficient to buy a number of the eval boards than to design a custom board. Of course cost effectiveness will depend in part on whether the eval board costs a few tens of dollars or a few thousand. If the eval board does not quite have all the I/O facilities needed, it may be easy to add some via an expansion connector. If the board exposes the I2C SDA and SCL lines then it may be quite easy to fit a daughter board hooked up to those lines, ditto for an SPI bus. Or you could have something like a PC-compatible board with various PCI plug-in cards. Often it will be possible to handle the extra I/O facilities entirely in application space with no need for any HAL modifications, e.g. extra I2C device objects can be instantiated within application code. Sometimes the eval board will not be appropriate, e.g. its footprint may be too large for the intended application. If so a new board may be designed but based on the schematics of the eval board. This saves a lot of h/w design effort and reduces the risk of running into previously undiscovered h/w bugs. The existing platform HAL may work unchanged on the new h/w, with any extra I/O facilities again handled within application space, Or it may be necessary to make minor tweaks, e.g. change the linker script support to reflect a larger amount of RAM and change the ROM startup code with different SDRAM controller register values. You may also want a different ecos.db entry, a new target which specifies the same platform HAL but e.g. removes the ethernet device driver because that device is no longer accessible. Or it may be desirable to design a completely new board. This is particularly likely for high-volume cost-sensitive applications. Again it may still be possible to reuse an existing eval board platform HAL, but it is now more likely that a new platform HAL will be appropriate. It depends in large part on how well the platform HAL and higher level HALs were written, i.e. how well they can cope with minor board variations, and that in turn depends in part on the h/w design. There is an awful lot of variety in the embedded space - hence the need for a configurable operating system. Oyvind> Rather than tweaking an existing HAL (often a couple of Oyvind> changes are sufficient), I would recommend to copy the Oyvind> existing HAL to a seperate repository(including the Oyvind> section in the ecos.db) and then placing that HAL before Oyvind> the snapshot of the eCos CVS HEAD. Renaming the HAL, Oyvind> although I would encourage it, isn't stricly required and Oyvind> probably not a lot of effort to rename at some later Oyvind> stage. If that is how you want to work, that is fine - subject to graphical configtool limitations. If other people prefer to copy a platform HAL within the existing hierarchy, that is fine too. If yet other people prefer to munge an existing platform HAL, either by adding configury or by simply breaking the HAL for the original board, that is fine too - although obviously any changes that break things are unlikely to make it back into the master repository. I have no particular desire to shoehorn people into exactly one way of doing things, except when absolutely necessary to maintain a coherent and maintainable architecture for the configuration system. (Note this does not justify any major reorganization of the master eCos repository that could make life more complicated for novice users etc.) 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