Freescale HAL licencing + processor selection help

[Gedare Bloom]

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.
>
Wonderful

> Specifically we are looking at various Freescale Kinetis processors,
> the Atmel SAMV70/71, the STM32 line, and the LPC lineup as well.
>
I don't have as much experience with these processors, but I think the
lpc and stm are better represented in RTEMS.

>
> Our main objectives are selecting a processor family that has peripheral
> compatibility across a range of performance classes.
>
> This is motivated by the desire to maintain as small a code base as
> possible.
>
> In the ideal world, they would all be supported by the RTEMS driver
> architecture, making it easy to move between them, but getting to this ideal
> world may take time.
>
The "driver architecture" in RTEMS is a bit misleading, but driver
support is getting better and if you stick to a single processor
family then you will likely have the most reuse possible.

>
> Questions
> ---------
>
> All of this being said, I'll finally get around to my questions.
>
>
>
> 1) What is the correct way to integrate 3rd party code into the RTEMS tree?
> The Freescale Kinetis SDK seems appropriately licenced to be included.
> However, I imagine there are other concerns. The things that come to mind
> are:
>         How can we fit these drivers into the RTEMS architecture? We don't
> want to introduce a new I2C abstraction. Does it make sense to use the
> Freescale HAL layer to build up the RTEMS I2C abstraction? Or does it make
> more sense to start from scratch? I see a distinct efficiency advantage in
> using the existing code and building the abstractions on top.
>
>         Worst case, we can use the Freescale code and not contribute it back
> to the tree if there insurmountable problems. However, I (and my company)
> would like to contribute our efforts back to the community.
>
You have a few options, and this applies to whatever vendor-supplied
code you need. If the code is licensed properly [1] (permissive
without an EULA to download it) then you can submit it for inclusion
into RTEMS in the BSP. This has been done for some hardware libraries,
most notable recent example in RTEMS is in
c/src/lib/libbsp/altera-cyclone-v/hwlib.

[1] https://devel.rtems.org/wiki/Developer/Contributing#LegalRequirements

In case the license is problematic for directly including, then you
can consider options for building the library separately from RTEMS
and linking it into your application. Or you can write code from
scratch.

Writing from scratch, or even stripping code out of
appropriately-licensed vendor sources, probably gives you the best
chance at having a modest code size and insight into maintenance. It
can also let you leverage the (evolving) frameworks in RTEMS for
drivers, such as in cpukit/dev/i2c for I2C, and in cpukit/libdrvmgr
[experimental stuff there]. This may lead to long-term benefits in
terms of code size and reuse, and less reliance on the upstream vendor
to provide patches etc. But the up front cost is obviously higher.

> 2) Given the motivation to keep a small code base, what processor families
> do any of you advise we take a look at? Has anyone had experience with this
> particular design goal and interested in shedding some light?
>
Are you worried about source code size or compiled code size, or both?
Some users have reported varying mileage in getting a small compiled
size, and there are lots of tricks available to reduce the binary size
of RTEMS. As far as source code size goes, I guess the biggest factor
would be the amount of code you need to drive the I/O peripherals.
Everything outside of that should be pretty much equivalent within
RTEMS.

> 3) For cortex M series, what kind of experiences have people had with
>         A) Atmel SAMV
>         B) Freescale Kinetis
>         C) NXP (LPC line)
>         D) STM32
>
>  Are there any distinct differences between these in your experience?
>
RTEMS has BSPs for some processors from C and D, see
c/src/lib/libbsp/arm/lpc* and arm/stm32f, so that part at least is
easy to get started. (However, the cost to develop or sponsor a
minimal BSP is not much with respect to choosing the correct platform
for your needs.) Perhaps some users who have used one of these BSPs
may chime in about their maturity and capabilities. I suspect the
LPC/NXP is better supported presently in RTEMS.

> P.S., the licencing and integration questions are equally applicable to
> other chip manufacture supplied code. I choose to discuss Freescale since
> it's high on our list.
>
> Thanks,
>
> --
> Isaac Gutekunst
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users