2

If you go to the official Arduino Nano Every page and click the Tech Specs tab, you'll see that it lists it as running at 20Mhz.

arduino nano every 20mhz

Turn On Verbose Compile

However, if you go into the Arduino IDE and go to File...Preferences... and turn on the Show Verbose Output during: compilation then you can examine how the board is actually set when a program is uploaded.

show verbose output

Examining the Output

When you look at that output you will see that it seems to be setting the board to run at 16Mhz.

snapshot of compilation output

Am I Looking At This Properly?

It looks to me as if the board is actually set to run at 16Mhz, right? Am I looking at that properly?

Extra Question

I'm attempting to confirm this because I am :

  1. writing code in Arduino IDE
  2. Compiling in Arduino IDE (to generate HEX file).
  3. Uploading to a stand-alone 40-pin ATMega4809

The ATMega4809 datasheet states the following:

16/20mhz datasheet

If I upload that sketch to the ATMega4809 40-pin chip, that means it will expect to run at 16Mhz, right?

Set Fuses?

Will the 40-pin chip be set to 16Mhz by the HEX file or will I need to set fuses on the chip to insure the chip is running at 16Mhz?

FYI - Compiled For Correct Board

Also you may wonder if I had the wrong board selected when I compiled, but here you can see I chose the Nano Every.

board set to nano every

5

With the Nano Every they went out of their way to make it look like as much like original Nano, to the point of providing that "register emulation" feature to make it appear that it has the 328P's older style of GPIO registers. Running at 16MHz just make sense if you want to behave like the common Nano as much as possible.

If you want to convince yourself that it's running at 16 MHz, you can blink an LED with causes of __builtin_avr_delay_cycles(16000000); in between. This busy-waits for the requested number of cycles. If it's running at 20 MHz instead of 16, you would see something faster than a 1 second delay.

They keep the configuration fuse values in a file fuses_4809.bin. On further investigation, it's not entirely clear what that file is for, despite containing the correct values. The actual OSCCFG value being used (which is the same in the file) is defined there directly in the boards.txt:

nona4809.bootloader.OSCCFG=0x01

OSCCFG documentation from datasheet.

So you can see it's set for 16 MHz on the Nano Every. The -DF_CPU in the command line originates from a line in boards.txt for the Nano Every:

nona4809.build.f_cpu=16000000L

and works its way into the compile command-lines via a line in platfrom.txt:

recipe.cpp.o.pattern="{compiler.path}{compiler.cpp.cmd}" {compiler.cpp.flags} -mmcu={build.mcu} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.cpp.extra_flags} {build.extra_flags} "-I{build.core.path}/api/deprecated" {includes} "{source_file}" -o "{object_file}"

The D_CPU macro exists to inform the compiled code what frequency it will be running at. The OSCCFG is controlling the actual frequency, it's important that they agree for any timing related code.

When you upload it's the "-Ufuse2:w:{bootloader.OSCCFG}:m" that becomes "-Ufuse2:w:0x01:m" in the avrdude command line generated from the upload recipe in platform.txt that has the actual effect of configuring the chip for 16 MHz.

If you really wanted to run at 20 MHz, you could try tweak the definitions of these, but it probably makes more sense to look at something like MCUdude MegaCoreX which appears to have a board definition for the ATMega4809 at 20 MHz.

6
  • Thanks for the info and idea. I will try that and see what I get.
    – raddevus
    Jun 28 at 14:08
  • Thanks a ton for that additional info on FREQSEL. I was reading datasheet and attempting to figure out how all that is set. Really helps. 👍🏽
    – raddevus
    Jun 28 at 14:56
  • 1
    I just updated because I noticed the bin file isn't actually used in avrdude. They're taking values directly from boards.txt properties, which has the same OSCCFG anyway. But I changed it for accuracy.
    – timemage
    Jun 28 at 15:01
  • 1
    The second to to last paragraph is more explicit on how the chip becomes programmed to 16 MHz, that is programmed with the 16 MHz oscal value. Something I should have mentioned earlier, more clearly. This is the same command-line, same instance of running avrdude that issues the -U:flash:file.hex:i that gets your compiled sketch code into the chip. I'll integrate that later if I have cause to edit again.
    – timemage
    Jun 28 at 15:20
  • 1
    So much helpful information. Thanks again for adding so much. It's helping me get my code flashed to the chip so I can test. Really great.
    – raddevus
    Jun 28 at 15:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.