Freescale HAL licencing + processor selection help

[Isaac Gutekunst]

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

The initial interest in these processors is due to the apparent diversity with similar hardware peripherals. I've looked and K and V (specific subfamilies actually) processors have the same UART and SPI peripherals.
>
> > 
> > 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. 

By driver architecture I mean cpukit/dev/i2c for I2C, and cpukit/libdrvmgr. 

We'd like to see something similar for CAN, CANOpen and maybe EtherCAT.

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

I'll look into the license and make sure I didn't agree to an EULA to download it.

We will have to think carefully about the tradeoffs here. I would like to write drivers "from scratch" if possible, but our time table may be prohibitive.


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

We are concerned with source code size from a mental overheard point of view. 

We want to write the same code and run it on a number of processors with different performance/price/size characteristics. The less mental context switching and APIs to know the better.

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

We are definitely open to commissioning or co-developing a BSP if it makes sense.


Thanks for the detailed response!

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