[ECOS] AT91SAM7SE - multiple defintion of CYGNUM_HAL_RTC_PERIOD

[ECOS] AT91SAM7SE - multiple defintion of CYGNUM_HAL_RTC_PERIOD

[Brian Karr]

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

[ECOS] Re: AT91SAM7SE - multiple defintion of CYGNUM_HAL_RTC_PERIOD

[John Dallaway]

Brian Karr wrote:

> Greetings, first post from a long-time lurker on the list.

Hello, Brian.

> 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

I cannot reproduce the multiple definition from current eCos CVS using
the at91sam7sek target and setting CYGNUM_HAL_ARM_AT91_CLOCK_TYPE ==
"EXTCLOCK".

From system.h:

> #define CYGBLD_HAL_PLATFORM_H <pkgconf/hal_arm_at91sam7sek.h>

From pkgconf/hal_arm_at91sam7sek.h:

> #include <pkgconf/hal_arm_at91sam7.h>

From pkgconf/hal_arm_at91sam7.h:

> #define CYGNUM_HAL_RTC_CONSTANTS 1
> #define CYGNUM_HAL_RTC_NUMERATOR 1000000000
> #define CYGNUM_HAL_RTC_NUMERATOR_1000000000
> #define CYGNUM_HAL_RTC_DENOMINATOR 100
> #define CYGNUM_HAL_RTC_DENOMINATOR_100
> #define CYGNUM_HAL_RTC_PERIOD 15000
> #define CYGNUM_HAL_RTC_PERIOD_15000

So CYGNUM_HAL_RTC_NUMERATOR is defined by the variant HAL and this
suppresses the fallback definition of CYGNUM_HAL_RTC_PERIOD in kernel.h.

Try saving your configuration to a new location and building from scratch.

I hope this helps...

John Dallaway

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

RE: [ECOS] Re: AT91SAM7SE - multiple defintion of CYGNUM_HAL_RTC_PERIOD

[Brian Karr]

Hi John,

Thanks for the response. That caused me to have another look at my board
package. Comparing it to the at91sam7sek I see that I was not properly
including hal_arm_at91sam7.h in the package CDL's define_proc..

The build is completely clean now. 

Cheers,

Brian

> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
> owner@ecos.sourceware.org] On Behalf Of John Dallaway
> Sent: Saturday, September 05, 2009 1:35 AM
> To: brian@briankarr.com
> Cc: ecos-discuss@ecos.sourceware.org
> Subject: [ECOS] Re: AT91SAM7SE - multiple defintion of
CYGNUM_HAL_RTC_PERIOD
> 
> Brian Karr wrote:
> 
> > Greetings, first post from a long-time lurker on the list.
> 
> Hello, Brian.
> 
> > 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
> 
> I cannot reproduce the multiple definition from current eCos CVS using
> the at91sam7sek target and setting CYGNUM_HAL_ARM_AT91_CLOCK_TYPE ==
> "EXTCLOCK".
> 
> From system.h:
> 
> > #define CYGBLD_HAL_PLATFORM_H <pkgconf/hal_arm_at91sam7sek.h>
> 
> From pkgconf/hal_arm_at91sam7sek.h:
> 
> > #include <pkgconf/hal_arm_at91sam7.h>
> 
> From pkgconf/hal_arm_at91sam7.h:
> 
> > #define CYGNUM_HAL_RTC_CONSTANTS 1
> > #define CYGNUM_HAL_RTC_NUMERATOR 1000000000
> > #define CYGNUM_HAL_RTC_NUMERATOR_1000000000
> > #define CYGNUM_HAL_RTC_DENOMINATOR 100
> > #define CYGNUM_HAL_RTC_DENOMINATOR_100
> > #define CYGNUM_HAL_RTC_PERIOD 15000
> > #define CYGNUM_HAL_RTC_PERIOD_15000
> 
> So CYGNUM_HAL_RTC_NUMERATOR is defined by the variant HAL and this
> suppresses the fallback definition of CYGNUM_HAL_RTC_PERIOD in kernel.h.
> 
> Try saving your configuration to a new location and building from scratch.
> 
> I hope this helps...
> 
> John Dallaway
> 
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss



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

[ECOS] Numonyx/ST Micro M29W320EB support

[Brian Karr]

Hi,

As older flash parts are becoming difficult to source, we are looking at
newer parts such 
as the Numonyx M29W320. Is there a driver in eCos that I can use for this
part?

We use the AM29LV160 driver for the M29W160 without problems, so it was
worth a try
to use the AM29LV320 driver with the M29W320, but the chip is not
recognized.

Any pointers would be appreciated.

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

[ECOS] RE: AT91SAM7SE - multiple defintion of CYGNUM_HAL_RTC_PERIOD

[Brian Karr]

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