Freescale HAL licencing + processor selection help

Tue Jun 16 13:46:31 UTC 2015

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.

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?

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