New BSP Advice

Joel Sherrill joel.sherrill at
Fri Sep 18 21:35:07 UTC 2015

On September 18, 2015 2:30:02 PM CDT, Gedare Bloom <gedare at> wrote:
>On Fri, Sep 18, 2015 at 3:29 PM, Gedare Bloom <gedare at> wrote:
>> On Thu, Sep 17, 2015 at 2:42 PM, Isaac Gutekunst
>> <isaac.gutekunst at> wrote:
>>> We will send in a patch at some point.
>>> The BSPs are two new BSP based off the existing STM32F4 BSP. The
>>> 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
>>> 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
>>> 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:
>> Naming Rules:
>> 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

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
>> 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
>>>>> 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
>>>>> process moving. I understand many of you are busy with the 4.11
>>>>> and if you can't offer much help at the moment, we understand. On
>>>>> 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
>>>>> request.
>>>>> The in progress code is viewable here:
>>>> Normally, you just submit patches to the devel mailing list. We
>>>> 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
>>>>> Cambridge Research Laboratory
>>>>> Vecna Technologies, Inc.
>>>>> 36 Cambridge Park Drive
>>>>> Cambridge, MA 02140
>>>>> Office: (617) 864-0636 x3069
>>>>> Fax: (617) 864-0638
>>>>> Better Technology, Better World (TM)
>>>>> _______________________________________________
>>>>> devel mailing list
>>>>> devel at
>>> _______________________________________________
>>> devel mailing list
>>> devel at


More information about the devel mailing list