Adding new BSP's

[Corey Schuhen]

Hi Till,

I understand what you are saying and I fully agree with your position on this, 
basically, code duplication is usually BAD. The problem I face is, that the 
MCF5206 modules that are similar have been written to depend pretty heavily 
on the MCF5206 hardware and I do not want to change what is there that 
heavily, otherwise it may break things and will be hard to get a maintainer 
to accept the changes. 

My thoughts are, to add the new modules in a way that should make them as 
generic as possible. From then on, any other coldfire BSP's and CPU's can 
more heavily steal from them, changing only BSP.h. Hopefully also, somebody 
with MCF5206 hardware may feel like making that BSP also use these 
modules(pipe dream maybe?).

Corey

On Fri, 14 Oct 2005 11:50 am, Till Straumann wrote:
> Corey Schuhen wrote:
> >Hello all,
> >
> >I am in the process of trying to create a BSP for a MCF548x/MCF547x module
> >sold by phytec (1). I started by duplicating the libbsp and libcpu
> > MCF5206*
>
> one of the most important things to do is *not to duplicate
> unnecessarily* but
> 'inherit' functionality. In the past, e.g., in the PowerPC area a little
> jungle of
> slightly different copies of very similar files have spread. It is a
> real pain to
> maintain these and to merge bugfixes into all variants...
>
> Please consider the following methods:
>
> A) try to make your BSP run-time compatible, if possible (i.e., if your
> board is very similar
> to an existing one), i.e., enhance the existing BSP to support your
> board as well and let
> it make run-time decisions.
>
> B) if your board is significantly different but similar enough to re-use
> (inherit) big parts of
>     another BSP:
>
> a) Try to use files existing files by pointing VPATH to the 'parent'
> BSP's relevant source area(s)
> b) Sometimes you'll find that an existing file cannot be used but some
> details need to be
>     changed. DO NOT COPY THE EXISTING FILE in this case. Instead,
>     try to separate usable/more generic parts and highly board-specific
> pieces into separate
>     files (and submit those modifications as PRs).
>     Then 'inherit' (VPATH) the generic parts and 'override' the specific
> pieces by providing
>     your own implementation.
>     Sometimes, the necessary specification can be achieved by defining
> appropriate macros
>     in BSP-specific headers (such as bsp.h).
>
> HTH
> -- Till
>
> >directories, .cfg along with changes to various Makefile.* files. So far I
> >have interrupt-driven serial and the clock timer working. Both the Hello
> > and Ticker sample applications seem to work.
> >
> >What is the procedure for supplying my mods back to the project? Should I
> > be creating a patch or requesting CVS access? Which branch(s) am I best
> > to work with? Currently I am working off the 4.6.4 release from tarballs.
> >
> >Regards,
> >
> >Corey
> >
> >(1) http://www.phytec.com/sbc/32bit/pcMCF548x.htm