Freescale HAL licencing + processor selection help

Fri Jun 12 22:44:08 UTC 2015

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/