New BSP Advice

[Gedare Bloom]

On Thu, Sep 17, 2015 at 2:42 PM, Isaac Gutekunst
<isaac.gutekunst at vecna.com> wrote:
> We will send in a patch at some point.
>
> The BSPs are two new BSP based off the existing STM32F4 BSP. The motivation
> is to keep the old BSP that includes only RTEMS contributed code. The new
> BSP includes lots of 3rd party ST code to make development and supporting
> multiple processors easier.
>
> The change will probably be broken into a few pieces:
>
> ADD STM32 HAL code
> Add Shared STM32F7 and STM32F4 code.
> Add each BSP
> Add CAN driver to RTEMS
> Add CAN driver implementation to the BSPs
>
>
> The reason fro breaking up the HAL code into a separate commit is that it
> adds hundreds of files that make it hard to find the relevant new code
> written by Vecna.
>
Good, the HAL code may need special approval to get on the mailing
list anyway. Also, point to relevant licensing info for it when you
push your code out. I will try to take a look at GitHub as time
permits, but my time is limited. I'll take a serious look when the
code appears here though.

>From my quick glance at GitHub, relay to your team the links to:
RTEMS Coding Conventions:
https://devel.rtems.org/wiki/Developer/Coding/Conventions
Naming Rules: https://devel.rtems.org/wiki/Developer/Coding/NamingRules

Especially, any public (extern'ed) functions in RTEMS follow some
naming conventions, for example functions located in the
arm/shared/stm32fxxx should be named like stm32f_...().

Adhering to the style rules will help alleviate some common reasons
for iterating on patches. We are most concerned in locations of shared
code, but now we are also less lenient about custom BSP code, since
that code often gets copied into new BSPs and propagates the
"badness".

Gedare

> Thanks for the info,
>
> Isaac
>
>
>
> On 09/17/2015 11:53 AM, Joel Sherrill wrote:
>>
>>
>>
>> On 9/17/2015 9:09 AM, Isaac Gutekunst wrote:
>>>
>>> Hey RTEMS Developers,
>>>
>>> Vecna has recently reached the final stretch of our BSP development
>>> effort for the STM32F4 and STM32F7 families of processors. We would love
>>> to contribute it back and where wondering what we should do to get that
>>> process moving. I understand many of you are busy with the 4.11 effort,
>>> and if you can't offer much help at the moment, we understand. On our
>>> end, we are performing internal peer review through the GitHub
>>> interface, and are hoping to wrap things up in about two weeks.
>>> Outstanding areas are the LWIP port which is not visible in the pull
>>> request.
>>>
>>> The in progress code is viewable here:
>>> https://github.com/vecnatechnologies/rtems/pull/4
>>
>>
>> Normally, you just submit patches to the devel mailing list. We don't
>> tend to review github pull requests. Just not part of the workflow
>> and we want everything centrally recorded.
>>
>> Is the BSP a variant of an existing one or a completely new one?
>>
>> Normally any BSPs outside the BSP itself are submitted for review
>> first. Then the BSP is put up for review.
>>
>> We still don't have a collection of LWIP drivers. I will start
>> another thread for that.
>>
>>>
>>> Kind Regards,
>>>
>>> Isaac Gutekunst
>>> Embedded Systems Software Engineer
>>> isaac.gutekunst at vecna.com
>>> www.vecna.com
>>>
>>> Cambridge Research Laboratory
>>> Vecna Technologies, Inc.
>>> 36 Cambridge Park Drive
>>> Cambridge, MA 02140
>>> Office: (617) 864-0636 x3069
>>> Fax: (617) 864-0638
>>> http://vecna.com
>>>
>>> Better Technology, Better World (TM)
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel