New BSP Advice

[Joel Sherrill]

On September 18, 2015 2:30:02 PM CDT, Gedare Bloom <gedare at rtems.org> wrote:
>On Fri, Sep 18, 2015 at 3:29 PM, Gedare Bloom <gedare at rtems.org> wrote:
>> 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_...().
>>
>P.S. do not reformat HAL (or other upstream, 3rd party code). And, of
>course, keep any patches to that code separate, and attempt to get it
>upstream.

I don't think we have a policy but I like to see third party code submitted unmodifed and then changes layered on. If all the changes are ifdef __rtems__, then it isn't a problem. The goal is to be able to merge new versions of the upstream easily.

>> 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

--joel