[ECOS] RE: AT91SAM7SE - multiple defintion of CYGNUM_HAL_RTC_PERIOD

["Brian Karr" <brian@briankarr.com>]

Removing the clock speed issue from the discussion, by changing the PLL
multiplier to 116 from 125, the cpu clock speed comes down to a safe 54.567
MHz.

More importantly, if I go directly into the platform CDL and change the
defaults to my preferences, and remove all of the associated settings from
my ecm file, I still get multiple definitions of CYGNUM_HAL_RTC_PERIOD. The
only difference here seems to be CRYSTAL vs. EXTCLOCK for
CYGNUM_HAL_ARM_AT91_CLOCK_TYPE.

Best,

Brian

> -----Original Message-----
> From: Brian Karr [mailto:brian@briankarr.com]
> Sent: Friday, September 04, 2009 12:54 PM
> To: 'ecos-discuss@ecos.sourceware.org'
> Subject: AT91SAM7SE - multiple defintion of CYGNUM_HAL_RTC_PERIOD
> 
> Greetings, first post from a long-time lurker on the list.
> 
> I am developing software for the at91sam7se512, using an external 22.579
MHz xtal
> to generate clocks.
> 
> I'm hoping to find the source of a build warning when I make the kernel
and app, and
> an archive search hasn't uncovered any clues.
> 
> After configuring for EXTCLOCK and setting
> CYGNUM_HAL_ARM_AT91_CLOCK_OSC_MAIN to 22579000, during the build I get
> multiple definitions of CYGNUM_HAL_RTC_PERIOD in the auto-generated
> pkgconf/kernel.h and pkgconf/hal_arm_at91sam7.h
> 
> 
> pkgconf/kernel.h
> 
> /***** proc output start *****/
> #include <pkgconf/system.h>
> #include <pkgconf/hal.h>
> #include <pkgconf/infra.h>
> #include CYGBLD_HAL_PLATFORM_H
> #ifndef CYGNUM_HAL_RTC_NUMERATOR
> # define CYGNUM_HAL_RTC_NUMERATOR     1000000000
> # define CYGNUM_HAL_RTC_DENOMINATOR   100
> # define CYGNUM_HAL_RTC_PERIOD        9999
> #endif
> 
> 
> pkgconf/hal_arm_at91sam7.h
> #define CYGNUM_HAL_RTC_PERIOD 36749
> 
> 
> My application make is necessarily set to treat warnings as errors, so I
would like to
> fix this warning. I can build a working binary if I comment out the
kernel.h definition
> each time I generate a tree.
> 
> * The first question is, do I need to make other definitions or undefine
something to
> avoid this, or is this a possible bug?
> 
> * Also, this results in a 58799479 Hz clock speed, which is slightly
higher than the
> rated speed at 1.8v core voltage (55Mhz). It's working so far, but should
I adjust it
> down with the PLL and use that, or is 55MHz a conservative limit?
> 
> Thanks,
> 
> Brian


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss