KEA8 clock configuration

[alessiodemarchi]

Hi

I'm working with TRK-KEA8 board and try a simple toggle pin main cycle:

GPIOA_PTOR |= 0x00010000;   // LED toggle

with ICS configuration as FEI 40MHz and 20 MHz bus frequency:

ICS_C1 |= ICS_C1_IRCLKEN_MASK; /* Enable the internal reference clock*/

ICS_C3 = 0x90; /* Reference clock frequency = 31.25 KHz*/
while(!(ICS_S & ICS_S_LOCK_MASK)); /* Wait for PLL lock, now running at 40 MHz (1024 * 39.0625Khz) */
ICS_C2|=ICS_C2_BDIV(1); /*BDIV=2, Bus clock = 20 MHz*/

I'm expecting a two edge of LED toggle time less of 100 ns, bus I see about 800 ns of main cycle time.

What's wrong?

Thanks

Alessio De Marchi

[mjbcswitzerland]

Hi Alessio

1. Try

GPIOA_PTOR = 0x00010000;   // LED toggle

instead of

GPIOA_PTOR |= 0x00010000;   // LED toggle

It may speed it up 3x or 4x by avoiding the redundant OR function

2. Try commanding the Fast alias GPIO address (from 0xf8000000) instead since it is also quicker (eg.).

FGPIOA_PTOR = 0x00010000;   // LED toggle

assuming your environment recognises it.

Regards

Mark

Kinetis for professionals: http://www.utasker.com/kinetis.html
KEA8 http://www.utasker.com/kinetis/TRK-KEA8.html
KEA32 http://www.utasker.com/kinetis/FRDM-KEAZN32Q64.html
KEA64 http://www.utasker.com/kinetis/TRK-KEA64.html / http://www.utasker.com/kinetis/FRDM-KEAZ64Q64.html
KEA128 http://www.utasker.com/kinetis/TRK-KEA128.html / http://www.utasker.com/kinetis/FRDM-KEAZ128Q80.html

[alessiodemarchi]

Thanks Mark

Now my main is more faster. But I think that I'm not understand the Kinetis GPIO behavior.

It the system clock is 40 MHz, bus clock 20 MHz. If I write one value on GPIO_PTOR in the next tick of the clock I have to see the physical pin to change (ARM M0+ is a RISC, right?). So in a main with 6 assembly instructions (a pin toggle and a cycle jump is about 6 simple instruction) I expected in the pin a square wave of about 6 * 25ns = 150 ns, without any use of the execution pipelines.

Where I'm wrong?

[mjbcswitzerland]

Alessio

You still need to try FAST IO access since this should be faster. You may then obtain the speed that you expect because there won't be slow port writes.

To ensure fastest speed you may also need to run the code in SRAM (although a small loop will probably be in cache and not suffer from slow Flash access).

Regards

Mark