[NEW BSP] Mbed lpc1768 board

[Martin Boretto]

Hi Sebastian,

I am sending the new git patch attached.

Best regards.




Martin Boretto
Software Engineer

Taller Technologies - Argentina
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina

*Mobile:* [+54 358 4206995 (ARG)]
*Skype:* tinacho_b


2014-06-05 11:49 GMT-03:00 Sebastian Huber <
sebastian.huber at embedded-brains.de>:

> 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.
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140605/0365664e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lpc176x_bsp.patch
Type: text/x-patch
Size: 240136 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140605/0365664e/attachment.bin>