24 posts / 0 new
Author
Message

hello,

it's 8 years later, and i'm seeing blink times about double what they should be. Before i try the WinAVR fix above, i thought i'd check and see if that's still the recommended fix.

Ingredients

ATMega328P Xplained Mini

Atmel Studio 7.0.1652 on Windows 8.1

thx!

Last Edited: Fri. Mar 9, 2018 - 06:43 PM

If you post the shortest compliable, working program that demonstrates the problem it will help others to help you work towards a solution!

JC

Have you defined F_CPU?

Are you sure your xmini is operating at that frequency?

David (aka frog_jr)

Correct me if i'm wrong, but you didn't define F_CPU for the frequency that ATmega328P is currently running

What value is defined F_CPU? It seems defined 8000000 MHz.

Oh for goodness sake, this is the code on GitHub, nothing more than a simple blinky program.

Nowhere is F_CPU defined, though it must be for _delay_ms to work.  Until johnyradio tells us what frequency his chip is running at, and posts the code he is actually using, then there is absolutely nothing more we can contribute to this thread.

Also, this thread must have been split off an old post, but regardless of that why on earth is johnyradio talking about a trying a WinAVR fix when he has stated that he is using AS7?

// Program to blink the inbuilt LED of ATmega328P Xplained mini

#include <avr/io.h>
#include <avr/delay.h>

int main(void)
{
DDRB = 0xFF;	// Output
PORTB = 0xFF;	// Clear the PORTB

while (1)
{
_delay_ms(1000);
PORTB |= (1 << PINB5);		// Set
_delay_ms(1000);
PORTB &= ~(1 << PINB5);		// Reset
}
}

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Sat. Mar 10, 2018 - 07:51 AM

larryvc wrote:
Nowhere is F_CPU defined, though it must be for _delay_ms to work. Until johnyradio tells us what frequency his chip is running at, and posts the code he is actually using, then there is absolutely nothing more we can contribute to this thread.

Not also that it (F_CPU) could be set as a command-line option.  So one needs to see the actual full build commands/results.

AFAIK when the override of the F_CPU is done there is no notification.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

theusch wrote:
AFAIK when the override of the F_CPU is done there is no notification.

Granted, and I suspect this is the case, but my point is that we can't be certain of anything because the OP hasn't told us squat about his/her project.  All we have is a link to a poorly implemented blinky program for an ATmega328P.

The following is for the benefit of the OP.

ATmega328P Xplained Mini User Guide

According to the guide the chip is running at 16MHz.  F_CPU needs to be defined as such, either in the program or in AS7.

// Program to blink the on board LED of ATmega328P Xplained mini

#include <avr/io.h>

#define F_CPU 16000000UL
#include <util/delay.h>  // <avr/delay.h> was moved to <util/delay.h>

int main(void)
{
DDRB = 0xFF;	// All PORTB pins set to output
PORTB = 0xFF;	// Set all PORTB pins high - was incorrectly commented as // Clear PORTB

while (1)
{
// Toggle PORTB pin 5 every second
​		_delay_ms(1000);
PINB = (1 << PINB5);
}
}


"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Sat. Mar 10, 2018 - 06:06 PM

DocJC wrote:

shortest compliable, working program that demonstrates the problem

this may not be the shortest compliable(?) working program that demonstrates the problem, but it's a working program that demonstrates the problem, and it's relatively short. From the github link in my OP:

// Program to blink the inbuilt LED of ATmega328P Xplained mini
#include <avr/io.h>
#include <avr/delay.h>

int main(void)
{
DDRB = 0xFF;	// Output
PORTB = 0xFF;	// Clear the PORTB

while (1)
{
_delay_ms(1000);
PORTB |= (1 << PINB5);		// Set
_delay_ms(1000);
PORTB &= ~(1 << PINB5);		// Reset
}
}

this may not be the shortest compliable(?) working program that demonstrates the problem, but it's a working program that demonstrates the problem, and it's relatively short. From the github link in my OP:

Did you even read what I posted above?  Forget about the GitHub link code, it is wrong anyway.  I posted, in post #8, correct working code that you should use.

Are you really using AS7, and is it updated to the latest release?

Also, why were you going to use a WinAVR fix if you are using AS7?

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Sat. Mar 10, 2018 - 10:44 PM

And did you read what others have posted?  If you want comment on #9 then you need to tell us what speed your AVR is running at.  You have to tell your F_CPU value.  You have to tell us what blink times you expect.  You have to tell us what blink times you are getting.

Chances are, when you get those answers and construct your reply you will have resolves the situation.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

I cant help notice that the thread title says "double". If you have code that toggles an output like an LED then it takes TWO cycles round the loop to get back where you started, not just one. So if you toggle then delay 100ms (say) hoping to see 10 "flashes" per second then you won't. It will be 5 hertz not 10. Is this the "double" that's been mentioned?

Guys, calm down, i've been a little busy :)

Noob here. Bear with me.

The delay in the code is 1,000 ms, so the LED should switch once per second. I'm seeing about twice per second.

As some correctly figured out, i'm using the code in the github that i linked, verbatim. So all the replies saying "what's your code?" or "if your code is doing this or that...", plz look at the code on github.

As people noticed, that code does not specify frequency. Therefor, i guess the chip is running either at factory default freq for the chip, or factory default freq for the board. I researched, but could not find any info about "default frequency" for either, in thedevice datasheets or elsewhere. @larryvc mentioned 16mHz in the Guide. I already checked the Guide, but it wasn't clear to me that 16 mHz is the default freq for the uC:

"External target CLK 16 MHz at 5V, 8 MHz at 3.3V"

-- so that doesn't mean external clock?

"16 MHz mEDBG clock" ..."The mEDBG outputs its CPU clock ...connected to the ATmega328P clock input ...to have a synchronous clock ...to enable debugging."

-- i assume that means this clock rate only applies when you're debugging, no?

I'm now researching how to test the chip directly to determine it's current frequency. Haven't found the method yet, but i assume it can be found in Atmel Studio Device screens, or via terminal. I appreciate any suggestions.

Of course, i could experiment with defining F_CPU in my code, but that will have to wait until i obtain a new board. This board is no longer responding

thx!

Last Edited: Mon. Mar 12, 2018 - 05:04 PM

I'm now researching how to test the chip directly to determine it's current frequency.
Well you could do worse than start by reading its fuses. Chances are (like most AVR new from the factory (apart from the VERY recent ones!)) it will be running at 1MHz. For "old school" chips that is because the default clock selection (CLKSEL fuses) specifically select a 1MHz internal oscillator - the old chips had 4 to choose from: 1MHz, 2MHz, 4MHz and 8MHz. "modern" (so anything from 2005/2006 onwards) AVR have just a single internal oscillator that runs at 8MHz but they also have a mechanism (CLKPR register) to scale that speed up and down and another fuse (CLKDIV8) that is enabled by default causes CLKPR to be preloaded with a divide-by-8 value. So again the chip runs at 1MHz.

Code such as <util/delay.h> and _delay_ms(1234) require YOU to know how fast the chip is going and tell them by defining a macro called F_CPU. So the usual usage would be something like:

// Program to blink the inbuilt LED of ATmega328P Xplained mini
#define F_CPU 1234567UL

#include <avr/io.h>
#include <avr/delay.h>
etc.


The 1234567 in this case is wrong - just an example but in this case I would be telling the delay routines that it's my belief that the chip is running at 1.234567 MHz. Once you are happy you know what you chip is running at you replace 1234567 with the speed in Hertz.

If you read your fuses and the setting of CLKSEL tell you it is "external crystal" then the only way to know how fast the clock is going (short of measuring it with an o'scope, logic analyzer or frequency meter) is to read the markings on the metal can that is attached to the XTAL1/XTAL2 pins of the chip. The same would be true if it is "external clock" rather than "external crystal". If the metal can said 3.6864 (say) you can be fairly sure it means 3.6864MHz in which case you'd now set the code to be:

// Program to blink the inbuilt LED of ATmega328P Xplained mini
#define F_CPU 3686400UL


etc.

PS I'll still make the point that in:

	{
_delay_ms(1000);
PORTB |= (1 << PINB5);		// Set
_delay_ms(1000);
PORTB &= ~(1 << PINB5);		// Reset
}

this is going to cause a 1s on, 1s off cycle so the whole on-off cycle will take TWO seconds not one (once you get F_CPU set right).

PPS some people (and I'm one of them!) think this is wrong but <util/delay.h> actually has this:

#ifndef F_CPU
/* prevent compiler error by supplying a default */
# warning "F_CPU not defined for <util/delay.h>"
/** \ingroup util_delay
\def F_CPU
\brief CPU frequency in Hz

The macro F_CPU specifies the CPU frequency to be considered by
the delay macros.  This macro is normally supplied by the
environment (e.g. from within a project header, or the project's
Makefile).  The value 1 MHz here is only provided as a "vanilla"
fallback if no such user-provided definition could be found.

In terms of the delay functions, the CPU frequency can be given as
a floating-point constant (e.g. 3.6864E6 for 3.6864 MHz).
However, the macros in <util/setbaud.h> require it to be an
integer value.
*/
# define F_CPU 1000000UL
#endif

The #ifndef says "if no one bothered to define F_CPI before they included <util/delay.h>" it ends up simply assuming 1000000UL (that is 1MHz). So even if you don't give a value for F_CPU you get one anyway. If you are lucky the 1MHz here just happens to be the speed of your AVR anyway - but not everyone is that lucky!

Last Edited: Mon. Mar 12, 2018 - 05:17 PM

An 8000000 F_CPU and a 16000000 F_CPU would explain it.

Perhaps OP's IDE defaults to 8000000.

International Theophysical Year seems to have been forgotten..
Anyone remember the song Jukebox Band?

skeeve wrote:
Perhaps OP's IDE defaults to 8000000.

Why won't OP simply answer the questions?  What speed is OP telling the toolchain the AVR is running at -- the F_CPU setting?  Does the generated .LSS give us a hint?  Why doesn't OP simply put an F_CPU in the source and then we can all know?  [I swear that the first time I looked at the github program there was a PINB write in it...]

theusch wrote:
And did you read what others have posted? If you want comment on #9 then you need to tell us what speed your AVR is running at. You have to tell your F_CPU value. You have to tell us what blink times you expect. You have to tell us what blink times you are getting. Chances are, when you get those answers and construct your reply you will have resolves the situation.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

theusch wrote:
[I swear that the first time I looked at the github program there was a PINB write in it...]
Not the GitHub version.

In post #8 I gave him a fully working version of code all set up to run on his ATMega328P Xplained Mini and its default F_CPU of 16MHz.  In fact I posted the datasheet there for him to read.

​If he would have taken the time to try that code he probably wouldn't be in the mess he is.

​@johnyradio, For the most part the boards work straight out of the box, no muss, no fuss.  The chip runs off a 16MHz crystal.

Even more evidence that the ATmega328P (target chip) runs at 16MHz.  Was it so difficult to accept what you've been told as fact?

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Tue. Mar 13, 2018 - 03:55 AM

@johnyradio, tell us where you are located and someone close to you may be able to help rescue your board for you.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

clawson wrote:

@clawson, many thanks for a superb, informative answer. It will take me some time to understand and apply your great notes.

theusch wrote:
What speed is OP telling the toolchain the AVR is running at -- the F_CPU setting?

As you can see in the github code i provided, the  F_CPU is not set in the code. As i mentioned i'm a beginner, so it's not out of stubbornness that i have not provided F_CPU, but rather because before this thread i did not even know what F_CPU is, let alone how to set it. Thx to this post, i now know F_CPU may be set in the IDE. As soon as i have a new, working board, i'll check that-- i assume the board must be connected to do so.

larryvc wrote:
I gave him a fully working version of code all set up to run on his ATMega328P Xplained Mini and its default F_CPU of 16MHz.

Yes you did. I understand now that i can fix this issue by setting F_CPU in the code. Thx for that. My understanding is that #define F_CPU 16000000UL does not change the clock, rather it informs the compiler or delay lib the clock rate of the chip.

Now my desire is to determine the clock rate.

larryvc wrote:
​If he would have taken the time to try that code he probably wouldn't be in the mess he is.

i'm not in a "mess", i'm learning. You sound upset. No need to get upset.

larryvc wrote:
Even more evidence that the ATmega328P (target chip) runs at 16MHz.

i asked above what "target clk" means. Can you say?

My understanding is that #define F_CPU 16000000UL does not change the clock, rather it informs the compiler or delay lib the clock rate of the chip.

Correct.

 "Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience.  Experience comes from bad judgement." "When you hear hoofbeats, think horses, not unicorns." "Fast.  Cheap.  Good.  Pick two." "Read a lot.  Write a lot." "We see a lot of arses on handlebars around here." - [J Ekdahl]

...Now my desire is to determine the clock rate.

larryvc wrote:

​If he would have taken the time to try that code he probably wouldn't be in the mess he is.

i'm not in a "mess", i'm learning. You sound upset. No need to get upset.

larryvc wrote:

Even more evidence that the ATmega328P (target chip) runs at 16MHz.

i asked above what "target clk" means. Can you say?

Why do you assume I am upset?  You have already to us that you have issues with your ATMega328P Xplained Mini, that is the mess I was referring to.  I gave you advice to tell us your location so that someone close to you might offer to fix your non-responsive board.  If you lived close enough to me I would try to fix it for you and send it back to you at my cost.  Do you really think that a person that was upset would do such a thing?  I am also in the middle of helping you in your other thread.  To quote your comment "calm down", you too, we are trying to help you.

The "target" is the ATmega328P chip on the ATMega328P Xplained Mini board.  The "target clk" is the frequency that the ATmega328P chip on the ATMega328P Xplained Mini board is running at.  Look at the lower screenshot in post #17, in the list of features you will find "16MHz target clk".  The schematic shows a 16MHz crystal connected to the ATmega328p chip (the target).

​When you get a board to run the code that I posted, then we can help you determine what frequency your chip is actually running at.  Until then, we all need to wait.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Now my desire is to determine the clock rate.

That part is pretty easy, now that the F_CPU part is sorted out.

If you tell the compiler that the micro is running at 8 MHz, (with the F_CPU directive), and you flash an LED at once per second, and it flashes at once per second, then life is good.  Your micro is running at the 8 MHz you thought it was.

If it is flashing at 2 Hz, twice as fast, then the clock must be twice as fast: 16 MHz.

If the LED is flashing slowly, at 1/8 th the desired (expected) 1 Hz rate, then the clock must be running at 1/8 th of 8 MHz, or 1 MHz, (likely because a Div by 8 Fuse is set to be active).

The above approach is certainly "good enough" to tell you if the Fuses are set to run on the external crystal or if the micro is running on the internal RC oscillator.

Once you have confirmed that the micro is running on the external crystal, for example, your done.

If the Xtal is 16.000 MHz, then you know, precisely, what the clock is, (within the precision of the Xtal and the oscillator circuit, which will be very close to the Xtal freq).

For more precise measurement of the micro's clock, (although the above method is often all that is required), you can sometimes route a buffered clock signal to a hardware pin, ClkOut, and then measure it with an O'scope, frequency meter, or a logic analyzer.

You can also set a Timer/Counter up in CTC mode, to generate a pulse on a hardware pin at a known frequency, (based upon the micro's clock freq, the pre-scaler, and the divider in the T/C), and then again measure the output on an O'scope and work backwards to determine the micro's clock, (or variants on this approach).

For most projects knowing that you micro is running at 16 MHz is the info you are after, and you don't usually need to know that it is running at 16.001375 MHz, (for example).

JC

larryvc wrote:
If you lived close enough to me I would try to fix it for you and send it back to you at my cost.

wow, thx!  quite generous. But, prolly better learning experience if solve it on my own.

larryvc wrote:
The "target" is the ATmega328P chip on the ATMega328P Xplained Mini board. schematic shows a 16MHz crystal

With a crystal oscillator, fuses can set a divisor, to divide down the crystal, correct?

"External target CLK 16 MHz at 5V, 8 MHz at 3.3V" -from Xplained Mini guide.

Does that mean that, with a 3.3V supply, the crystal oscillator will run at 8 MHz?

If this refers to the chip that's on the Xplained board, why is it called "external"?

btw, i'm reinstalling AS, hoping it will recognize the board.

thx

Last Edited: Thu. Mar 15, 2018 - 09:17 AM

With a crystal oscillator, fuses can set a divisor, to divide down the crystal, correct?

Yes.