[NEW BSP] Mbed lpc1768 board

[Daniel Gutson]

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.

Thanks Sebastian!

    Daniel.

>
> --
> 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.
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel



-- 

Daniel F. Gutson
Chief Engineering Officer, SPD


San Lorenzo 47, 3rd Floor, Office 5

Córdoba, Argentina


Phone: +54 351 4217888 / +54 351 4218211

Skype: dgutson