Freescale HAL licencing + processor selection help

Tue Jun 16 16:46:16 UTC 2015

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/
>>
>