From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13789 invoked by alias); 1 Jun 2007 08:54:22 -0000 Received: (qmail 13780 invoked by uid 22791); 1 Jun 2007 08:54:21 -0000 X-Spam-Check-By: sourceware.org Received: from anchor-post-36.mail.demon.net (HELO anchor-post-36.mail.demon.net) (194.217.242.86) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 01 Jun 2007 08:54:18 +0000 Received: from calivar.demon.co.uk ([83.104.54.243] helo=xl5.calivar.com) by anchor-post-36.mail.demon.net with esmtp (Exim 4.42) id 1Hu2ti-000KZH-K8; Fri, 01 Jun 2007 08:54:14 +0000 Received: from xl5.calivar.com (localhost [127.0.0.1]) by xl5.calivar.com (Postfix) with ESMTP id 691FF138700; Fri, 1 Jun 2007 09:54:13 +0100 (BST) To: Jim Seymour Cc: ecos-discuss@ecos.sourceware.org References: <465DBB45.3070802@cipher.com> From: Nick Garnett Original-Sender: nickg@ecoscentric.com Date: Fri, 01 Jun 2007 08:54:00 -0000 In-Reply-To: <465DBB45.3070802@cipher.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] CDL define_proc: Unable to put "extern" in an include files X-SW-Source: 2007-06/txt/msg00002.txt.bz2 Jim Seymour writes: > > What I'm trying to do is allow for our system clock speed to be a > run-time variable, instead of a fixed constant. This means that the > #define's that get generated for CYGNUM_RTC_PERIOD (and the like) will > refer to a global variable. Without an "extern" statement, these > references will cause a compiler error. There are other ways to achieve this. The way I have done this in the past is not to make CYGNUM_RTC_PERIOD variable. Too much code assumes that this value is a constant; it uses its value on startup to calculate some scaling factors, or whatever, and then doesn't read it again. So even if CYGNUM_RTC_PERIOD were to vary, the original derived values would still be used. Instead, where I want to run the system at different clock speeds I express CYGNUM_RTC_PERIOD is terms of a fictional fixed rate clock; usually around 1MHz, but you can go as low as 1KHz if you want. Then, in HAL_CLOCK_INITIALIZE(), I calculate the real clock period using the current system clock rate. The selected period is saved in the HAL, so when I change the system clock rate I can recalculate the real period (just recalling HAL_CLOCK_INITIALIZE() does the trick usually). Obviously HAL_CLOCK_READ() also needs to do some arithmetic to translate system clock ticks back into ticks of the fictional clock. -- Nick Garnett eCos Kernel Architect eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss