Freescale Kinetis SDK Preview

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Freescale Kinetis SDK Preview

7,247 Views
xinyu_chen
NXP Employee
NXP Employee

Hey, everybody, it is a good news. Freescale has already started to develop complete Driver library and middleware for ARM Cortex M0+/M4 Kinetis Families MCU. It is called Kinetis Platform SDK (Software Development Kit), which is similar with STM32 Peripheral Driver Lib and NXP LPCOpen. SDK’s goal is to support all Kinetis chip by providing complete IP register access abstract layer (HAL) and complete device driver based on the HAL. User can use the set of driver library conveniently to implement own applications, without reading complicated chip’s reference manual. At the same time, the unified driver interface also ensures application’s porting between different Kinetis chip easily. In addition, the SDK will provide RTOS support (including MQX, FreeRTOS, and uCOS), USB and TCP/IP protocol stack, detailed application demo as well as various convenient development tools. Now Kinetis SDK is under developing, several versions will be released this year. Coming soon~

Now let’s review the API and it’s usage of Kinetis SDK I2C, UART, and PIT peripheral drivers. Wish your valuable opinions, and support Freescale to provide better software solutions for our customers. Any of your ‘Like’, comments and criticism is very precious to us.

I have attached the PDF version of this preview, please open and look.

Labels (1)
15 Replies

4,371 Views
tim
Contributor I

I have been using the SDK for a few weeks now and have two questions.

1. It is mid-summer and I am looking for a release date.

2. I am using ThreadX RTOS.  Have you all validated the SDK with ThreadX?

Thanks,

Tim

0 Kudos
Reply

4,371 Views
SlaveToTime
Contributor II

Hello,

I am interested at this solution,but my platform is the Freescale Vybrid VF6XX, dual core processor with a Cortex-A5 Core plus a Cortex-M4 Core.

In the Cortex-M4 core,we are not using MQX, because it is not so necessary due to the fact that most of the peripherals shall be supported by linux.

Two questions:

1)Will be supported in the future Cortex-M4 of the Vybrid VF6XX by Kinetis SDK?and when?

2) I am interesting in particular to the CAN /FLEXCAN peripheral. What do you consider that will be the work needed to porting of the code?

Thank you

0 Kudos
Reply

4,371 Views
namhoang
Contributor I

I am looking for a chance to learn about FRDM-K64F! Count me on mountainmondays

0 Kudos
Reply

4,371 Views
EdSutter
Senior Contributor II

I recently downloaded the SDK and started using it. I was able to build what I wanted to build; but then decided to try to tune the flash usage.  I looked at the symbol table of my build to see what was in there, and I noticed a lot of duplicate named tables with the naming convention of __g_regs_PERIPHERAL_base_addresses (e.g. for uart, __g_regs_UART_base_addresses).  So digging a bit, I saw that the header files (e.g.MK64F12_uart.h) have this kind

of declaration:

static const uint32_t __g_regs_UART_base_addresses[] = {

        REGS_UART0_BASE,

        REGS_UART1_BASE,

        REGS_UART2_BASE,

        REGS_UART3_BASE,

        REGS_UART4_BASE,

        REGS_UART5_BASE,

    };

Initialized tables declared as static (hence linker doesn't complain at build time).  For my particular build, this table (plus others) exists 12 times!  Am I building something wrong or is this just a mistake in these header files?

I'm assuming this isn't what you want in the SDK true?  I apologize if this is an issue but was already reported...

Ed

0 Kudos
Reply

4,371 Views
jrychter
Contributor V

This effort is interesting, however I have two questions:

  • What is the progress and when can I expect working code? I am about to write an I2C driver and would like to know whether I should wait.
  • Why not stick to the CMSIS standards? As an example, CMSIS-Driver has a nicely designed consistent API for I2C. Why invent new APIs when there is already a widely accepted standard?
0 Kudos
Reply

4,371 Views
Stones
Contributor I

Hello, does this SDK support use of DMA? For example, I would like to use UART, I2C and SPI as DMA enabled peripherals, with the help of RTOS and interrupts to let CPU do more tasks while keeping data transferred by DMA. Can I set as I desired using this SDK? From the preview PDF, I cannot confirm this. Would you please help answer?

0 Kudos
Reply

4,371 Views
xiaodong_zhang
NXP Employee
NXP Employee

hi Xinyu,

    I review UART driver API, but I wonder if UART driver support DMA.

0 Kudos
Reply

4,371 Views
yifangguo-b4310
NXP Employee
NXP Employee

Hi yu,

   There is a third party company called "LPLD” that have developed a  set of API libary wraping the IP register of Kinetis actually. So  what is the SDK's advantage than "LPLD_OSKinetis_V2"  ?

0 Kudos
Reply

4,371 Views
bowerymarc
Contributor V

if you mean this one: The open source driver lib for Kinetis K60

It seems a good start but still is missing for example I2S and NFC.  Also it seems it's only for IAR, I didn't see any CW projects in there.

0 Kudos
Reply

4,371 Views
pgo
Senior Contributor V

Hi Xinyu,

It looks interesting.  My only questions are:

  • What the intended license will be?
  • Will it be compatible with using a RTOS such as CMSIS or FreeRTOS etc.

bye

0 Kudos
Reply

4,371 Views
chris_brown
NXP Employee
NXP Employee

Hi pgo,

To answer your questions,

  • What the intended license will be?
    • [response] The intent is to provide an unrestrictive, open-source license with the SDK.  Know that because of some of the components they want to include, there may be different licenses on those components.  There are still some on-going discussions on licensing I believe, but the intent is to provide an unrestrictive, open-source license. 
  • Will it be compatible with using a RTOS such as CMSIS or FreeRTOS etc.
    • [response] Yes, the SDK is targeting compatibility with MQX, FreeRTOS, uCOSII and uCOSIII through an OS abstraction layer.  This abstraction could easily be used to make the SDK compatible with other operating systems as well. 

Thanks for your questions,

Chris

0 Kudos
Reply

4,370 Views
thomasgrieger
Contributor III

Hi,

some suggestions and/or questions regarding the API.

I2C:

- shutdown function of I2C master versus slave is inconsistent (different parameters, instance vs. pointer)

- signature of I2C Slave init function is not consistent to example (function pointers are missing in signature

- type definition of i2c_master_t and i2c_device_t missing in the document

- Which information is stored in this structs?

- Why are they located outside the i2c module? They may be manipulated.

- How would a example look for a more complex i2c operation like reading an EEPROM, as in this case the master has to send some bytes with address information and then read some bytes from the slave?

- How do you prevent the concurrent usage from different drivers which use the i2c module (like eeprom or port expander)?

UART:

- Does the UART also have it's own return types?

PIT:

- How would a one-shot timer be realized using this API? Calling stop from callback function?

- How is concurrent usage of timers prevented? The API is missing return values.

0 Kudos
Reply

4,371 Views
bowerymarc
Contributor V

very interesting project.  I hope you include a full suite of tests to make sure the library is fully functional.

also, a good test of the library's efficiency is if you can use the library to access every peripheral on your smallest Kinetis (e.g. MKL04Z8VFK4)  and still have some RAM/ROM left over for application code.  ProcessorExpert, for example, can not pass this test.

it should also be usable (and tested) with C and C++ of course.

0 Kudos
Reply

4,371 Views
bobpaddock
Senior Contributor III

The use of 'const' is inconsistent.

Don't see 'volatile' used in relation to the UART interrupt handlers.

Without seeing all of the code that may not be an issue, taking the conservative stance in the meantime that it is an issue.

Do a search for this "volatile site:blog.regehr.org" .

Is the code MISRA compliant to the largest extend possible (100% compliance is never realistic)?

Any deviations are documented.

Activities - MISRA C

Has a static code analysis been done with any tools such as Lint or Coverity?

The Leader in Static Analysis for C/C++ -- PC-lint and FlexeLint

Software Development Testing and Static Analysis Tools

Don't really want to be seeing 'printf()' Et.Al. in library code.

May have only been the examples.

0 Kudos
Reply

4,371 Views
xinyu_chen
NXP Employee
NXP Employee

Bob Paddock wrote:

The use of 'const' is inconsistent.

Good suggestion, looks like I2C and UART does not have a consistent 'const' usage. We will go through all the APIs for this.

Don't see 'volatile' used in relation to the UART interrupt handlers.

Without seeing all of the code that may not be an issue, taking the conservative stance in the meantime that it is an issue.

Do a search for this "volatile site:blog.regehr.org" .

You mean the typedef struct UartState, which will be accessed in the ISR right? That's true, volatile should be added.

s the code MISRA compliant to the largest extend possible (100% compliance is never realistic)?

Any deviations are documented.

Activities - MISRA C

Has a static code analysis been done with any tools such as Lint or Coverity?

The Leader in Static Analysis for C/C++ -- PC-lint and FlexeLint

Software Development Testing and Static Analysis Tools

Don't really want to be seeing 'printf()' Et.Al. in library code.

May have only been the examples.

We follow the MISRA 2004 compliant by IAR build checking. And no printf in the drivers.

Thanks for your quick look and suggestion!!

0 Kudos
Reply