This is the mail archive of the
mailing list for the eCos project.
Re: at91 HAL patch
- From: Laurent GONZALEZ <laurent dot gonzalez at silicomp dot fr>
- To: "Koeller, T." <Thomas dot Koeller at baslerweb dot com>
- Cc: "'Laurent GONZALEZ'" <laurent dot gonzalez at silicomp dot fr>, ecos-patches at sources dot redhat dot com
- Date: Tue, 19 Aug 2003 17:50:38 +0200
- Subject: Re: at91 HAL patch
- Organization: SILICOMP RESEARCH INSTITUTE
- References: <850597605E79D21182830008C7A4B9CF1EB42651@COMM1>
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 :
#define MYBOARD_LED1 AT91_PIO_PIN9
#define MYBOARD_LED2 AT91_PIO_PIN10
and application code will be easier to port from a platform to another because (AFAIK)
is more widely used than
On Tue, 19 Aug 2003 16:41:27 +0200
"Koeller, T." <Thomas.Koeller@baslerweb.com> wrote:
> Sorry for confusing you. I was not referring to the PIO bit
> definitions here, what I meant to say was that it would be
> advantageous in general to move the #include to the end of
> var_io.h because I could then use any definitions from var_io.h
> as a basis for platform-specific #defines, so as to indicate
> the use a platform makes of a particular hardware feature.
> Thomas Koeller, Software Development
> Basler Vision Technologies
> An der Strusbek 60-62
> 22926 Ahrensburg
> Tel +49 (4102) 463-390
> Fax +49 (4102) 463-46390
> > -----Original Message-----
> > From: Laurent GONZALEZ [mailto:email@example.com]
> > Sent: Tuesday, August 19, 2003 4:14 PM
> > To: Koeller, T.
> > Cc: 'Andrew Lunn'; firstname.lastname@example.org
> > Subject: Re: at91 HAL patch
> > On Tue, 19 Aug 2003 15:39:34 +0200
> > "Koeller, T." <Thomas.Koeller@baslerweb.com> wrote:
> > > Just another related thought:
> > > Wouldn't it be more sensible to include the platform header
> > > (plf_io.h) at the end of var_io.h instead of near the beginning,
> > > as is the case now? Then its contents could refer to the
> > > definitions contained in var_io.h, for example, assign
> > > meaningful (in the platform context) names to I/O pins.
> > >
> > > tk
> > Yes, it is possible. But if you do that, all board (at91/ebxx
> > or at91/custom_board) that uses the same mcu (say at91r40807)
> > will provide the same definitions in their own plf_io.h .
> > PIO bit definitions should definitively be in var_io.h . As
> > at91/var provide support for several mcus, it should also
> > provide PIO bit definitions for each of them.
> > IMHO, at91_var shall contain the user API (eg register
> > definitions) and include processor specific var_io.h like
> > file for bit field definition (include/x40/x40_pio_pins.h,
> > include/x55/x55_pio_pins.h, ...).
> > regards,
> > --
> > GONZALEZ Laurent
> > Silicomp Research Institute
> > Tel: 04 76 41 66 98
Silicomp Research Institute
Tel: 04 76 41 66 98