Question about F_CPU Setting

Log in or register to post comments
Go To Last Post
13 posts / 0 new
Author
Message
Baldrian
Baldrian's picture
Level: Hangaround
Joined: Thu. Jul 10, 2008
Posts: 195 View posts
Location: Ruhrpott, Germany
#1
Posted by Baldrian: Fri. Aug 1, 2008 - 02:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

I have a noob question about F_CPU, because I don't really understand this stuff.

I have a project using AVRStudio 4. I set in the configuration the compiler option -DF_CPU=8000000UL.
I also put in my header file #define F_CPU 8000000UL

But it seems, this doesn't mean, that my controller is running on 8Mhz. Moreover it seems, that he is still running on the 1MHz internal clock.

1. Am I right?
2. Do I have to programm the fuse to set the clock to internal 8Mhz?
3. If so, for what is the compile option -DF_CPU if it has no influence on the real speed of the controller? Maybe the Answer is: Because than the compiler knows, how to put i.e. the delay into the ASM code. Is my assumption right? Are there other things I have to know for the -DF_CPU option?

Thanks in advance and regards
Baldrian

http://xkcd.com/221/

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101067 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Aug 1, 2008 - 02:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I set in the configuration the compiler option -DF_CPU=8000000UL.
I also put in my header file #define F_CPU 8000000UL

Do one or the other - not BOTH. (the command line config is probably preferable in fact)
Quote:
But it seems, this doesn't mean, that my controller is running on 8Mhz. Moreover it seems, that he is still running on the 1MHz internal clock.

You are quite right - to change the clock speed of an AVR you use the fuses or, in some, program CLKPR

To do this you need to decide what clock source you want to use and then get out your ISP programmer and (VERY CAREFULLY!) change the CLKSEL, CKDIV8, CKOPT, SUT fuses to your chosen setting

But which AVR are you talking about - you may be able to achieve the switch from internal 1MHz to internal 8MHz simply by setting the CLKPR register from within your running program.

Cliff

Oh and to answer (3) - the usual use of F_CPU is when it comes to calculating UBRR values for UART use or various timer settings, also possibly to use the software delays in util/delay.h - the only key thing is that the F_CPU you use matches the speed that the AVR is actually running at (as set by fuses/CLKPR)

Top
Baldrian
Baldrian's picture
Level: Hangaround
Joined: Thu. Jul 10, 2008
Posts: 195 View posts
Location: Ruhrpott, Germany
Posted by Baldrian: Fri. Aug 1, 2008 - 03:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for the fast and helpful reply.

clawson wrote:

But which AVR are you talking about - you may be able to achieve the switch from internal 1MHz to internal 8MHz simply by setting the CLKPR register from within your running program.

It's an ATMEGA16L.

clawson wrote:

To do this you need to decide what clock source you want to use and then get out your ISP programmer and
(VERY CAREFULLY!) change the CLKSEL, CKDIV8, CKOPT, SUT fuses to your chosen setting

Can I do it also with JTAG Programming?
When I read the fuse settings in studio for my ATMEGA16L, I can only see SUT_CKSEL, where some text is written behind that 1MHz internal is set.

About the "(VERY CAREFULLY!)": I read so many threads about people setting the wrong fuses and cannot program their controller anymore. That's why I'm asking here all this questions, before shooting my controller
8)

Regards,
Baldrian

http://xkcd.com/221/

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101067 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Aug 1, 2008 - 03:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes indeed you can use JTAG rather than ISP to do the fuse programming and one of the joys of using one of the Atmel interfaces rather than these rather half-baked ones is that you get to drive it with Studio which has a far more sensible (and less prone to error) mechanism for setting the clock fuses than ost other programming systems. If you go to that bit where it currently says "1MHz internal" then just drop the list and select "8MHz internal" instead. The program the fuses.

(PS the mega16L is one of the older ones that doesn't have CLKPR so the ONLY way to change to 8MHz is using this fuse programming method)

Top
Baldrian
Baldrian's picture
Level: Hangaround
Joined: Thu. Jul 10, 2008
Posts: 195 View posts
Location: Ruhrpott, Germany
Posted by Baldrian: Fri. Aug 1, 2008 - 03:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK. Thanks for the answer. I really appreciate that.

I did it the way you said and everything is working fine on 8MHZ. :D I rebuild my project with F_CPU=8000000UL and programmed it to the controller. Now the response to the STK500 switches is much more faster than before. I don't have to press the buttons until my fingers are bleeding anymore to switch through my LCD Menu.
Now the weekend can start 8)

Thanks again.
Baldrian

http://xkcd.com/221/

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101067 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Aug 1, 2008 - 04:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's something seriously wrong with the design of your program if you can notice any difference in button scanning between 1MHz and 8MHz operation. Simply winding up the clock to hide the design errors is unlikely to be the best solution.

Top
Baldrian
Baldrian's picture
Level: Hangaround
Joined: Thu. Jul 10, 2008
Posts: 195 View posts
Location: Ruhrpott, Germany
Posted by Baldrian: Fri. Aug 1, 2008 - 04:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The thing is: The programm is build for ATMEGA1280@16MHZ. But I don't have the controller yet. So, I reconfigured all the Ports to use the LCD on the ATMEGA16L and then started testing :lol:

http://xkcd.com/221/

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101067 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Aug 1, 2008 - 04:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes but button scanning should only be using a few % of even a 1MHz processor. There's no way you should be needing to run the processor at 8MHz or 16MHz just to scan a few buttons. If, for example, you leave the AVR at 1MHz but also define F_CPU to 1000000UL then does that "fix" things?

Top
Bronze Markbobgardner
bobgardner's picture
Level: 10k+ Postman
Joined: Wed. Sep 4, 2002
Posts: 26609 View posts
Location: Orlando Florida
Posted by bobgardner: Fri. Aug 1, 2008 - 04:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For the benefit of other perhaps new users, the FCPU define is specific to only one of the popular avr c compilers, so if you are not using the winavr/gcc/avrstudio compiler, the info about clock speed setting applies, but not the compiler specific FCPU define.

Imagecraft compiler user

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101067 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Aug 1, 2008 - 04:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bob,

This was a tricky choice - based on his mention of F_CPU it seemed like a GCC question and I thought about moving it for YOUR benefit - but it's actually a more general question about clock sources and fuses and, now, button scanning.

Cliff

Top
Baldrian
Baldrian's picture
Level: Hangaround
Joined: Thu. Jul 10, 2008
Posts: 195 View posts
Location: Ruhrpott, Germany
Posted by Baldrian: Fri. Aug 1, 2008 - 06:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually the button scanning takes not that much %. The timer interrupt for scheduler was bad configured. So, the buttons were scanned not that often. The software debouncing took also it's part to the problem. :D

So, everything is fine :D

Baldrian

http://xkcd.com/221/

Top
kmr
kmr's picture
Level: Raving Lunatic
Joined: Thu. Apr 1, 2004
Posts: 3720 View posts
Location: New Mexico
Posted by kmr: Fri. Aug 1, 2008 - 07:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Baldrian wrote:
So, everything is fine.
That's good news, thanks for letting us know.

Kevin Rosenberg
http://b9.com
http://kevin.hypershots.com

Top
ka7ehk
ka7ehk's picture
Level: 10k+ Postman
Joined: Fri. Nov 22, 2002
Posts: 21793 View posts
Location: Tangent, OR, USA
Posted by ka7ehk: Fri. Aug 1, 2008 - 09:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

THere is an important point that may have been missed, here.

Software does NOT have a universal way of knowing the clock rate. Yes, it can "know" it if the internal RC oscillator is used. But, when an external oscillator of any kind is used, it cannot tell.

The result is that YOU have to tell the compiler what the clock frequency is. That is what F_CPU and its variants is all about.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Top