Blackfin BSP

[Alain Schaefer]

Hello,

I think the current state cpu/bfin/rtems/bfin.h is because of my
laziness and me not wanting to take
a decision when I did this implementation.

IHMO the correct would be to break up bfin.h. All the periphery defnes like
UART, SPORT, RTC etc. should be moved to something like
libbsp/bfin/shared/include/bfin.h
and there create a bfin533.h which includes bfin.h. The bsp would then
include bfin533.h.
The same would apply for bsp of other variants.

After this split the bfin.h in cpukit should only really contain core
defines which should be the same in
all bfin variants. If there would be still differences (maybe L1??)
the bfin.h could include a variant specific .h depending
upon a CPU model define like Allan suggested.

just my 2 cents.

Alain

On Dec 5, 2007 3:39 PM, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
> Allan Hessenflow wrote:
> > Hello,
> >
> > I've started on a BSP for a bf537 based board.  I took a copy of the
> > ezkit533 bsp and, with only trivial changes, got it to work on the
> > bf537.  So I'm about to start writing drivers for some additional
> > peripherals, most significantly the ethernet module in the bf537.
> >
> > Since this is a BSP I'll be able to contribute back to RTEMS, I
> > thought I'd ask if there's any preference on how to do the peripheral
> > definitions.  Currently, under cpukit, there's a bf533.h that defines
> > the locations of the peripherals that chip has.  There is a lot in
> > common between different members of the blackfin family, so the bf537
> > definitions could easily be put in the same file, controlling the
> > differences with a CPU model define.  In that case I'd rename it to
> > something more generic.  Or, the definitions could be put in a new
> > file, bf537.h; that file would then duplicate most, if not all, of the
> > contents of bf533.h.  Personally I'd prefer the former to eliminate
> > that duplication.  I only see a couple of advantages to the latter -
> > there wouldn't be any additional #ifdef's, and it would cut down on the
> > changes I'd be making to files that are maintained by someone else.
> >
> >
> Duplicating the bulk of a header file is definitely bad!
>
> The solution to sharing the contents varies.  A single
> .h file with conditionals for CPU models could become
> very large and unwieldy.   It could also break under its
> own complexity as the family grows.
>
> If this is a case where there is a completely common
> base bfin and each CPU model adds things to it, I would
> probably lean to something like a base header file and
> CPU model specific header file that includes the base
> one and then adds on to it.
>
> I see someone else replied to this message.  Hopefully
> you all can make a suggestion based upon what the
> bfin CPU model family is shaping up like.
>
> We have spent a long time fighting back at similar
> issues in the PowerPC port where it is hard to find
> the common ground so making a good decision is
> important to long term maintenance.
>
> Without a lot other than experience on other architectures
> to go by, I would lean to the second option -- a base
> architecture .h and a model specific one.  It could even
> be structured like this:
>
> bfXXX.h
>    + define feature flags
>    include bfin shared header file
>   add more definitions
>
> Then BSPs include a specific bfXXX.h and the shared code
> for maintenance is invisible to them.
>
> \
> --joel
>
> > allan
> >
> >
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>