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.
> 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
