RE: New BSP Advice
Hi RTEMS Developers, Sorry, what finally happened to STM32F BSP, after a few emails with this subject? Looking at the latest master on git.rtems.org, I see the folder "stm32f7x" exists in c\src\lib\libbsp\arm directory, but it has just a "hal" folder and its files have never been used. Best Regards, Afshin Jamaali -Original Message- From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Isaac Gutekunst Sent: Thursday, September 17, 2015 18:40 To: devel@rtems.org Subject: New BSP Advice 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 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
Re: New BSP Advice
On Mon, Sep 21, 2015 at 10:11 AM, Isaac Gutekunst wrote: > Hi Sebastian, > > The zip file contains a number of files that we don't want, even inside the > relevant sub-directory. Should the commit bring in only the file we care > about? > Yes. > Of course, for the fortunately very minor modifications, we will wrap them > with > > #ifdef __rtems__ > #else > #endif > > In a subsequent commit. Thanks. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New BSP Advice
Hi Sebastian, The zip file contains a number of files that we don't want, even inside the relevant sub-directory. Should the commit bring in only the file we care about? Of course, for the fortunately very minor modifications, we will wrap them with #ifdef __rtems__ #else #endif In a subsequent commit. Isaac On 09/21/2015 09:53 AM, Sebastian Huber wrote: Hello Isaac, this sounds all right in case all the files added to RTEMS provided by ST contain this header in the ZIP file distributed by ST. One commit should add all these files unmodified. A download link for this ZIP file in the commit message would be nice. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New BSP Advice
Hello Isaac, this sounds all right in case all the files added to RTEMS provided by ST contain this header in the ZIP file distributed by ST. One commit should add all these files unmodified. A download link for this ZIP file in the commit message would be nice. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New BSP Advice
Hi Sebastian, The license is standard BSD. Every file includes this 3-clause header ** * @attention * * © COPYRIGHT(c) 2015 STMicroelectronics * * Redistribution and use in source and binary forms, with or without modification, * are permitted provided that the following conditions are met: * 1. Redistributions of source code must retain the above copyright notice, * this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright notice, * this list of conditions and the following disclaimer in the documentation * and/or other materials provided with the distribution. * 3. Neither the name of STMicroelectronics nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * ** */ https://lists.rtems.org/pipermail/users/2015-June/029027.html An update regarding the meeting we had in June: We where unable to get conclusive information from the FAE regarding licensing, and where not able to make further contact. If you recall the conversation back in June, the main issue is that the code is downloaded as a zip file that contains an overarching license that is NOT okay. However, many of the sub folders contain additional release notes that state the BSD 3-clause license. I did NOT accept an EULA in order to download it. We believe the top level licenses does not pollute the nested licenses. Having talked to a number of people with legal experience, it is extremely clear that each file is BSD licensed. In addition, there is no competitive advantage lost by allowing their HAL code to be used in open source projects, and everything to be gained by having RTEMS support their chips. With this reasoning, there is practically no risk using the code, as we are doing something mutually beneficial for all parties. Note: This is not legal advise, just my personal reasoning. Isaac On 09/21/2015 01:33 AM, Sebastian Huber wrote: Hello Isaac, what is the license of the ST code? The last time I looked at this code it had a license incompatible to open source projects. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New BSP Advice
Hello Isaac, what is the license of the ST code? The last time I looked at this code it had a license incompatible to open source projects. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New BSP Advice
On September 18, 2015 2:30:02 PM CDT, Gedare Bloom wrote: >On Fri, Sep 18, 2015 at 3:29 PM, Gedare Bloom wrote: >> On Thu, Sep 17, 2015 at 2:42 PM, Isaac Gutekunst >> 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
Re: New BSP Advice
On Fri, Sep 18, 2015 at 3:29 PM, Gedare Bloom wrote: > On Thu, Sep 17, 2015 at 2:42 PM, Isaac Gutekunst > 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
Re: New BSP Advice
On Thu, Sep 17, 2015 at 2:42 PM, Isaac Gutekunst 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_...(). 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
Re: New BSP Advice
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. 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
Re: New BSP Advice
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 -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
