Freescale HAL licencing + processor selection help

Tue Jun 16 17:01:04 UTC 2015

On Tue, Jun 16, 2015 at 12:51 PM, Isaac Gutekunst
<isaac.gutekunst at vecna.com> wrote:
> Do you have any advise when talking to ST? I will ask if it is possible to
> release the HAL code separately, or to clarify the licencing.
>
Chris Johns has had some direct interactions with vendors about this
problem before and might have advice.

One way to get started is to see if they already provide some
suitably-licensed code for Linux. A lot of vendors do so already
because of market reasons, but don't realize how this problem affects
smaller market segments like RTOSs.

While I haven't been in any of these talks, from what I have heard the
main sticking point seems to be that vendors are hesitant to release
code that might possibly be useful on competitors' products. For HALs
and drivers, this hesitancy makes little sense, so being convincing
about how the code can possibly be used (i.e. it really is only useful
to drive their boards) may help. And, again, it can help if you can
point to other drivers the vendors may have released for Linux or
other mainstream OS.

Gedare

> We are meeting with two people from ST this Friday and will have an
> opportunity to ask them about licencing, so any advice would be useful.
>
> Thanks,
>
> Isaac
>
>
>
> On 06/16/2015 12:46 PM, Gedare Bloom wrote:
>>
>> On Tue, Jun 16, 2015 at 9:46 AM, Isaac Gutekunst
>> <isaac.gutekunst at vecna.com> wrote:
>>>
>>> Pavel,
>>>
>>> You bring up some very good points about motor control. We'll definitely
>>> keep the quadrature encoder input/timer requirements in mind.
>>>
>>> The LPC line does not seem to have as broad a range of chips, especially
>>> on
>>> the higher end. We are talking to a representative from NXP in a couple
>>> of
>>> days, and he may be able to shed some light on their road map.
>>>
>>> Forward Progress and a Few More Questions
>>> ------------------------------------------
>>>
>>> Based on our requirements, it's looking like the STM32F series makes a
>>> lot
>>> of sense.
>>>
>>> The M4-M7 transition looks almost completely seamless (pin for pin
>>> compatibility, and similar if not identical peripherals).
>>>
>>> With STM32Cube, there could be a compatibility story from the M0 through
>>> the
>>> M7 which would be great for our objectives.
>>>
>>> We would probably build an RTEMS BSP on top of the STM32Cube HAL,
>>> assuming
>>> the licencing is OK. From what I can tell, all the cube HAL files are
>>> copyrighted but with a permissive licence.
>>>
>>>
>>> Has anyone figured out the Cube F7 licencing agreement?
>>>
>>> CubeF7:
>>>
>>> http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1897/PF261909
>>>
>>>
>>> Their top level licence
>>>
>>> is:http://www.st.com/st-web-ui/static/active/en/resource/legal/legal_agreement/license_agreement/software_license_agreement_liberty_v2.pdf?sc=software_license_agreement_liberty_v2
>>>
>>> This licence definitely NOT ok.
>>>
>> If you have to agree to that license to download the whole source
>> package including the below indicated drivers, then there is a murky
>> problem in that the top-level license quite clearly defines Licensed
>> Software to include everything (source, binary, documentation) you
>> download with that file. In this case, the vendor needs encouragement
>> to separately provide the HAL/Drivers.
>>
>>> However, the Drivers/STM342F7xx_HAL_Driver directory contains a
>>> Release_Notes.html with the following content: (Reformatted into ASCII by
>>> me)
>>>
>>>
>>> Release Notes for STM32F7xx HAL Drivers
>>> =======================================
>>>
>>> Copyright 2015 St Microelectronics
>>>
>>>
>>>
>>> Update History
>>> --------------
>>>
>>>          V1.0.0 / 12-May-2015
>>>
>>>          Main Changes
>>>          ------------
>>>          *First official release for STM32F756xx/746xx/745xx devices
>>>
>>> License
>>> =======
>>>
>>> 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.
>>>
>>> Each source file contains the same licence block.
>>>
>>>
>>> Are these acceptable to add into the RTEMS tree?
>>>
>> Yes, this appears to be a standard 3-clause BSD, which is suitable, if
>> these source files are not separately encumbered as I noted above.
>>
>>> Thanks,
>>>
>>> Isaac
>>>
>>>
>>>
>>>
>>> On 06/12/2015 06:44 PM, Pavel Pisa wrote:
>>>>
>>>>
>>>> Hello Isaac,
>>>>
>>>> On Friday 12 of June 2015 22:26:10 Isaac Gutekunst wrote:
>>>>>
>>>>>
>>>>> On Jun 12, 2015 14:53, Gedare Bloom <gedare at rtems.org> wrote:
>>>>>>
>>>>>>
>>>>>> On Fri, Jun 12, 2015 at 12:25 PM, Isaac Gutekunst
>>>>>>
>>>>>> <isaac.gutekunst at vecna.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Dear RTEMS Community,
>>>>>>>
>>>>>>> Background
>>>>>>> ----------
>>>>>>>
>>>>>>> I'll give a little background before jumping into the my questions:
>>>>>>>
>>>>>>> I am starting a robotics project utilizing RTEMS at Vecna. We are
>>>>>>> evaluating a number of Cortex M series processors for this platform.
>>>>
>>>>
>>>>
>>>> I would add some two cents of thoughts based on my experience with
>>>> RTEMS.
>>>> I have tested RTEMS on some ARMs, PowrPC and x86 and even 68k in the
>>>> past
>>>> but we have only real long term (many years) experience with RTEMS based
>>>> applications in medical instruments running on the first Freescale i.MX
>>>> members which are now completely dated.
>>>>
>>>> We have decided to use LPC178x/lpc408x for one of our newer robotic
>>>> system because that was one of the best RTEMS supported contemporary ARM
>>>> based chips. I am happy with ETHERNET and IPv4 RTEMS support for
>>>> that architecture. One remark for code organization, LPC408x BSP is
>>>> little
>>>> hidden in "rtems/c/src/lib/libbsp/arm/lpc24xx" directory because
>>>> it is continuation of LPC24xx series in integrated peripherals etc.
>>>> But configure options are straightforward, i.e. for the case with SDRAM
>>>> it is
>>>>
>>>>     --enable-rtemsbsp="lpc17xx_ea_ram"
>>>>     --enable-rtemsbsp="lpc40xx_ea_ram"
>>>>
>>>> As for LPC in general, we have used these from 21xx days. Now we use
>>>> LPC1768
>>>> without OS. We have applications on LPC408x without OS but we plan to
>>>> use
>>>> RTEMS when TCP/IP or more complex tasks are required.
>>>>
>>>> Significant disadvantage of NXP LPC products for some kind of robotics
>>>> applications is availability of single only quadrature signal (IRC)
>>>> interface and I have heard that they have been asked by users to add
>>>> more of these but they have no scheduled part (at least year ago).
>>>> This can be OK if you plan to have all motors controlled by distributed
>>>> manner. But sometimes you need two sensors even for single axis
>>>> (one on motor shaft, one on precisely positioned part). Because
>>>> we have sometimes demand for multiaxes systems with precise
>>>> coordination we have combined MCU with FPGA
>>>>
>>>>     http://pikron.com/pages/products/cpu_boards/lx_cpu.html
>>>>
>>>> Even that designs is really interesting and provides advanced
>>>> control features, the combination of MCU and FPGA makes system
>>>> expensive for some applications. We use LPC IRC/QEI interface
>>>> on much smaller LPC1768 based single axis systems. But QEI
>>>> is not well designed, there is obscure mechanism to count and compare
>>>> indexes and measure speed in HW but most usable feature to capture
>>>> IRC counter position at index pulse is missing same as capability
>>>> to capture time of the last counted edge which would enable much
>>>> simpler way to estimate precise position at time of control loop
>>>> sample time interrupt.
>>>>
>>>> The STM microcontrollers have more counters which can count
>>>> IRC signals and from quick look it seems to be capable
>>>> to do capture of the position at arrival of external signal.
>>>> On the other hand, LPC QEI is clean 32-bit but STM counters
>>>> are mostly 16-bit or may be some mix.
>>>>
>>>> Both of these are child toy when compared to eQEP found on
>>>> some of Ti's Cortex-A AM335x or Cortex-R RM48 chips.
>>>> But original Luminary Micro have exactly same strange
>>>> QEI as LPC.
>>>>
>>>> As for the maximum Flash size, LPC408x 512 kB maximum seems to
>>>> be problem for some of our larger applications and LPC43xx
>>>> (offers even 1MB Flash) series is not supported by RTEMS
>>>> (if I have not overlooked something) yet.
>>>>
>>>> As for the CAN, there has been report of somebody on RTEMS list
>>>> that he uses CanFestival for CANopen on RTEMS. Porting should
>>>> be/is relatively easy. CanFestival generates compact code for
>>>> fixed object dictionary devices. There exists attempt
>>>> of our group at Czech technical University to provide more
>>>> dynamic CANopen infrastructure but it is not fully complete
>>>> and in active development now. But I would be happy to see
>>>> this infrastructure ported to RTEMS one day and we may return
>>>> to that if there is demand and projects
>>>>
>>>>     http://ortcan.sourceforge.net/
>>>>
>>>> As for the safety critical/sensitive applications, I think that
>>>> the reasonable architectures (maily for single MCU systems)
>>>> are some of PowerPCs and Ti's Cortex-R TMS570/RM48 because these
>>>> architectures provide dual-core in lockstep, ECC etc. LPC and ST
>>>> are out of such play. Some of such equipped MPC56xx and QorIQ
>>>> are supported by RTEMS. One of my students is working on initial
>>>> TMS570 support included in RTEMS now but that is far from
>>>> beeing easily usable for production environment still. The header
>>>> files license was a big problem to solve which ended in full
>>>> headers rewrite.
>>>>
>>>> As a longer term activity, I would be happy if we can have
>>>> Matlab/Simulink target for RTEMS. This is area where we have
>>>> contracts at our university for Ti's tools embedded TMS570/RM48
>>>> targets and which we prepared for Linux as well.
>>>>
>>>> Best wishes,
>>>>
>>>>                   Pavel
>>>> --
>>>>                   Pavel Pisa
>>>>       e-mail:     pisa at cmp.felk.cvut.cz
>>>>       www:        http://cmp.felk.cvut.cz/~pisa
>>>>       university: http://dce.fel.cvut.cz/
>>>>       company:    http://www.pikron.com/
>>>>
>>>
>