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

Laurent GONZALEZ <> 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.

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.

Nick Garnett                    eCos Kernel Architect      The eCos and RedBoot experts

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