[NEW BSP] Mbed lpc1768 board

[Sebastian Huber]

On 2014-06-05 16:14, Daniel Gutson wrote:
> Hi Sebastian,
>
> On Thu, Jun 5, 2014 at 10:49 AM, Sebastian Huber
> <sebastian.huber at embedded-brains.de>  wrote:
>> >On 2014-06-05 15:20, Marcos Díaz wrote:
>>> >>
>>> >>At first we started developing this bsp inside that folder. Although
>>> >>it has many similarities with the lpc1778, it has other differences:
>>> >>There isn't an external memory controller for our bsp.
>>> >>The pinselect is very different for our board (it has more
>>> >>similarities with the one for the lpc24xx). Also the GPIO
>>> >>The start configuration for the main clock and the pll is quite
>>> >>different. And other things
>>> >>
>>> >>The macros used for the differentiation of those boards referred to
>>> >>the CPU architecture (ARM_MULTILIB_ARCH_V4 ARM_MULTILIB_ARCH_V7M) and
>>> >>in some cases we could use the functions for the lpc 24xx,in others
>>> >>for the lpc1778, and in others new code.
>> >
>> >
>> >We had this problem also on the Freescale MPC5500 and MPC5600 chips.  This
>> >ARM_MULTILIB_ARCH_V4 and ARM_MULTILIB_ARCH_V7M could be replaced with
>> >something else.  For example
>> >
>> >http://git.rtems.org/rtems/tree/c/src/lib/libbsp/powerpc/mpc55xxevb/configure.ac
>> >
>> >http://git.rtems.org/rtems/tree/c/src/lib/libcpu/powerpc/mpc55xx/include/regs.h
>> >
>>> >>We created a macro for our
>>> >>bsp, but we should have changed many other macros already placed. Our
>>> >>Idea was to not break any existing code, since we can't test for the
>>> >>other boards.
>>> >>Is it still preferred to merge this new bsp with others?
>> >
>> >
>> >I think there is a considerable amount of copy and paste involved here, but
>> >I didn't review it very closely.
> We are aware of the copy-paste and agree that it is excessive, but also
> think that the best solution would involve a refactor in the other 2 BSPs
> to re-arrange common code of the three BSPs so it can be reused.
> Since this is our first contribution, and we did need this BSP working,
> we thought that it was better to do this in a two stages asking for
> agreement: first, a "self-contained" BSP in the form we are submitting it now,
> and a second stage, discussions in the middle, of refactor involving the
> three BSPs.
>
> Would you agree under these terms? We need to keep working in this BSP
> by adding more drivers; we are more than willing to do the refactor of the three
> BSPs as part of our development.
>
>   So in case you think it is infeasible to
>> >integrate this BSP into standard the LPC2400 and LPC1700 directory, then we
>> >can add your specialized BSP.  My feeling is that this will generate more
>> >work in the long run though.
> Agree, please see above.

Ok, can you please re-send this BSP as a proper Git patch with author and 
commit message.

In the long run we have to get rid of the BSP centric approach in RTEMS.  This 
is what leads to this mass of copy and paste.  Drivers should be independent of 
the BSP.  Only the low-level startup and driver configurations should be part 
of the BSP (probably using some sort of a flattened device tree).

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.