joel.sherrill at oarcorp.com
Wed Dec 5 14:39:05 UTC 2007
Allan Hessenflow wrote:
> 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:
+ 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.
More information about the users