New BSP Advice

[Gedare Bloom]

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.

> 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