Adding new BSP's
corey_m at schuhen.net
Fri Oct 14 03:40:25 UTC 2005
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?).
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).
> -- 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.
> >(1) http://www.phytec.com/sbc/32bit/pcMCF548x.htm
More information about the users