This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
Re: at91 HAL patch
On 19 Aug 2003 11:05:21 +0100
Nick Garnett <nickg@ecoscentric.com> wrote:
> Laurent GONZALEZ <laurent.gonzalez@silicomp.fr> 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)
regards,
--
GONZALEZ Laurent
Silicomp Research Institute
Tel: 04 76 41 66 98