Kinetis fast IO operations?

[charleszimnicki]

This may be a basic questions but I am new to Kinetis and KDS. I am trying to migrate an 8-bit project with critical IO timing. To establish a baseline, I tried few tests with FRDM-K22F running at 120MHz and max other clock speeds. First, I started with mbed.org using their APIs (just because it was super simple). I wrote a very simple loop flipping a couple of pins using DigitaOut(). To my surprise, the shortest period per IO operation was something on the order of 550ns. Then, (after quite a bit of struggle to set up KDS) I wrote a similar program using Processor Expert setup, switching pins with GPIO_DRV_ClearPinOutput() and GPIO_DRV_SetPinOutput(), again running at maximum achievable frequencies. And again, I got a similar result, over 500ns per operation. Then I performed a third test, using direct register access to IO pins. Finally, I was able to get an IO period of about 30ns - something I would expect from a part running at 120MHz.

My questions are very basic. If I want a "normal" IO speed, am I stuck trying to figure out how to write directly to registers? I can understand why the library functions have overhead, but over a magnitude slower? I know I can use peripherals for PWM, communications, etc, but unfortunately I need just rudimentary, fast IOs for this project. Any links to examples with fast IO would be very appreciated.

[mjbcswitzerland · Accepted solution]

Hi Charles

The API functions have a lot of overhead so that they can be used by beginners but of course when one prefers optimal use direct accesses must be used.

This is however also simple by using macros.

The uTasker project has a set of port macros that are compatible across all processors and have no call overhead.

See

Kinetis Port Macros

http://www.utasker.com/forum/index.php?topic=1664.msg5917#msg5917

By using such macros code can also be made cross-platform compatible (eg. projects can run on Kinetis and Coldfire with only the need to specify the port name according to the particular HW and not rewrite/optimise any access code.

Regards

Mark

Kinetis: µTasker Kinetis support

K22: µTasker Kinetis FRDM-K22F support / µTasker Kinetis TWR-K22F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[charleszimnicki]

Mark,

Thanks for the quick response and for the links. Would you also be able to point me to some examples (using direct register access), for timer setup?

FYI, my goal is to initiate periodic service (preferably using interrupts but it does not have to be this way), with high timing precision. This in turn will trigger some IO operations, A/Ds and some fast SPI communication (to be used in power conversion). In addition, I need to synchronize the service with 3-phase PWM. I figure that the same timer would need to drive PWM outputs and trigger a deterministic interrupt.

Again, I tried library functions but the "jitter" is about 1 micro-second. If my nominal frequency of the service is 100kHz, I would get (very insufficient) 10% resolution. Ideally, the service would need to have a period with the same number of CPU cycles.

[mjbcswitzerland]

Hi Charles

It depends on how you want to work the project.

One option is to just work with the data sheet and hardware header files since it is the lowest level and most direct implementation. If you want to be purely independent this is the best method but you may need to invest several weeks of learning the individual peripherals.

I have all direct register support in the uTasker project for the modules that you use, which are enclosed in APIs for easy usage [eg. http://www.utasker.com/docs/uTasker/uTaskerHWTimers.PDF ] and can be simulated. I also offer fast-track support at this forum (or personally for commerical users) if project/development is is of importance.

In your case it sounds as though you are developing with the FRDM-K22 but really need a more basic device without USB for a final product (K1x). The limitation will be the time base accuracy and synchronisation of the peripherals, although generally I would develop such things (motor control etc.) based on a single high priority timer interrupt because its jitter will also tend to zero but it won't restrict a comfortable frame work for the development itself.

Regards

Mark

Kinetis: µTasker Kinetis support

K22: µTasker Kinetis FRDM-K22F support / µTasker Kinetis TWR-K22F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market