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 18:33:19 +0100
Nick Garnett <nickg@ecoscentric.com> wrote:
> Laurent GONZALEZ <laurent.gonzalez@silicomp.fr> writes:
>
> > Okay, we're now on the same wavelength !
> > That's a good idea.
> > However, i think that the include should happen in the inverse order.
> > As plf_io.h will use var_io.h definition, the former should include the latter.
> > Thus plf_io.h will looks like :
> >
> > #include <cyg/hal/var_io.h>
> >
> > #define MYBOARD_LED1 AT91_PIO_PIN9
> > #define MYBOARD_LED2 AT91_PIO_PIN10
> > etc ...
> >
> > and application code will be easier to port from a platform to another because (AFAIK)
> > #include <cyg/hal/plf_io.h>
> > is more widely used than
> > #include <cyg/hal/var_io.h>
>
> No. Applications should never include var_io.h or plf_io.h directly,
> they should include hal_io.h only. If necessary this includes var_io.h
> which includes plf_io.h. Exactly where in each file the include
> happens is up to the HAL author(s). However, the usual approach is
> that it happens early so that the platform can define things to
> customize the variant, and the variant can define things to customize
> the architecture.
It makes sense.
>
> Note that it is not necessary for something used in a #define to
> actually have been defined at the time of definition. It only needs
> to be defined at time of use. So putting #defines in plf_io.h that use
> things defined later in var_io.h is quite OK. This sort of thing
> happens all the time.
Of course ! whatever am I thinking of ?
--
GONZALEZ Laurent
Silicomp Research Institute
Tel: 04 76 41 66 98