Jim Seymour <[EMAIL PROTECTED]> 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
