This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: at91 HAL patch

On 19 Aug 2003 11:05:21 +0100
Nick Garnett <> wrote:

> Laurent GONZALEZ <> writes:
> > Hi all,
> > 
> > What about target eb55 that uses this at91/var package ?
> > 
> > The rigth place for defining such bit field is in at91/var, it's
> > true, however at91/var's cdl file shall contain an option (using
> > interface - implements mechanism) that defines which series of mcu
> > the target (at91/ebxx or at91/custom_board) will use.  Using this
> > option, it will be easy to choose a dedicated file that import mcu
> > specifics definitions into var_io.h.
> Well, we already have the CYGHWR_HAL_ARM_AT91 option that must be set
> in the platform HAL to select the correct AT91 variant. This is used
> in var_io.h to differentiate between different power-saving
> devices. The same option should be used to select different sets of
> PIO pin definitions. 

True. To avoid problems the recently added definitions should be surrounded with the good #ifdef #endif directive.

>There's probably no need to do anything more
> complicated.

That's an other point. 
For me, the at91 family is a collection of IPs (usart, spi, aic, etc ...). Thus, the atmel's mcu could be view as ASIC that embeeds a subset of those IPs. Even at91/var package can be designed in a very modular fashion. There is no needs to do such complicated things, unless you aimed to be able to easily change/add/upgrade peripheral IPs or port to a real ASIC based on at91 technologies (eg. easycan from Europe Technologies)


Silicomp Research Institute
Tel: 04 76 41 66 98

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]