Kinetis Microcontrollers中的主题 clock issue

clock issue

vinkar — Thu, 26 Jun 2014 13:55:35 GMT

Hello Friends,

I am playing with my KL05 FRDM board. I did not modify any of the clock MCG registers. I believe, if I leave them as it is it will give me a clock of 20.97M.

So ,mathematically speaking each instruction should take about (1/20.97M) = 50uSecs. As an expt I tried the following code wherein I toggle a pin with a for loop sandwiched in the middle ( with a single iteration in the for loop). Now, when I check with my probe , I get almost 1.9uSecs as the time taken, which is ridiculously high.

Could anyone point where I am doing wrong. I think, something in the MCG registers is not working. I will look into that as well. ANy pointers will be appreciated.

My code -

#include "derivative.h" /* include peripheral declarations */

int main(void)

{

int tempCount,tempCount2 = 0;

// clocking //

SIM_SOPT2 |= 0x01000000; // clock sel for the timer0 //

SIM_SCGC5 |= 0x00000400; // gating of clock //

SIM_SCGC6 |= 0x01000000; // gating of timer //

PORTB_PCR8 |= 0x00000100; // alternative pin mux selection //

GPIOB_PDDR |= 0x00000100; // pin direction //

TPM0_CONF |= 192; // counter runs in debug mode as well //

TPM0_MOD = 1309; // period count //

while(1){

GPIOB_PSOR |= (1<<8);

for(tempCount = 0;tempCount <= 1;tempCount++);

GPIOB_PCOR |= (1<<8);

}

Re: clock issue

mjbcswitzerland — Thu, 26 Jun 2014 15:05:48 GMT

1/20.97MHz is 47ns - if yout test takes 1.9us to run it must be taking 40 clock cycles which may be realistic. Due to spead in DCO frequency (20..25MHz) this can vary slightly.

To be sure you need to look at the disassembled code to see how mayn cycles are involved.

Regards

Mark

Re: clock issue

bobpaddock — Thu, 26 Jun 2014 15:10:14 GMT

1/20.97 MHz = ~48 nano seconds. Not sure if you really mean micro seconds in your message, or just the wrong symbol is being used?

Also depending on your compiler and its optimization settings this line, maybe optimized away as it has no side-effects:

for(tempCount = 0;tempCount <= 1;tempCount++);

This would give the fastest toggle rate:

for(;;)

{

FGPIOB_PTOR = (1U << 8U)

}

Re: clock issue

vinkar — Thu, 26 Jun 2014 15:42:27 GMT

Hello Mark,

Thank u.

I am using the internal crystal. Maybe you have a point that the internal crystal may have some stability issues.

But, almost 40 cycles for just one for loop with 3 iterations is a wee bit long I guess.

I am using Code Warrior. Can u suggest how I can optimise my code. DOes Code Warrior do it automatically.

Vinod.

Re: clock issue

mjbcswitzerland — Thu, 26 Jun 2014 15:50:00 GMT

Vinod

You can change the optimisation setting in the compiler optimisation setup in CW.

I would step the code in the debugger (disassembly mode) to see how many instructions are involved and the modify optimisation to see what the effect is.

regards

Mark

Re: clock issue

vinkar — Thu, 26 Jun 2014 16:27:19 GMT

Hello Bob,

Thank u for your tips.

Can you point me to some such tutorials/docs that can be helpful in

optimising my code pls.

Vinod.

Re: clock issue

bobpaddock — Thu, 26 Jun 2014 16:41:36 GMT

Best thing to do is not optimize your code to soon. Just get it to work, then worry about optimizing it.

As Mark suggested look at the listing of what the compiler is producing.

Next read the documentation for your compiler, as to how it would handle code with no side effects and now it would handle 'volatile'. On the rare occasion where I use a busy loop I always put in a NOP that is marked as volatile to make sure the compiler won't get rid of what it thinks is a useless loop.

Everyone should read "Nine ways to break your systems code using volatile":

http://blog.regehr.org/archives/28

Re: clock issue

vinkar — Thu, 26 Jun 2014 17:02:54 GMT

Hello Bob,

The thing is I have PWM working and its 20Kh. This is for a motor (BLDC). During the on time of the PWM I am reading the ADC of the phases. But, say, for eg , if its 50% duty cycle, I have a window of about 25uSecs to measure the ADC. Now, if my code is so intense then I do not have much time to read the ADC and it is cumbersome . That is y I am looking at optimizing the code.

Also, I saw in the adc peripheral datasheet. It takes about 2uSecs to a max of 3.5uSecs to get an adc read. So I might end up not reading the adc many times.

As I mentioned , I am driving a BLDC motor using the KL04. Now, many of the off the shelf ones use an Atmel with a 16MH and lower. I am sure with the KL04 we can be as efficient, I believe.

Worst case , can I add assembly in code warrior :smileyhappy:

Vinod.