On September 18, 2015 2:30:02 PM CDT, Gedare Bloom <ged...@rtems.org> wrote: >On Fri, Sep 18, 2015 at 3:29 PM, Gedare Bloom <ged...@rtems.org> wrote: >> On Thu, Sep 17, 2015 at 2:42 PM, Isaac Gutekunst >> <isaac.guteku...@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.guteku...@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@rtems.org >>>>> http://lists.rtems.org/mailman/listinfo/devel >>>>> >>>> >>> _______________________________________________ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel --joel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
