Understanding clock speed in context of megaTinyCore

[nabelekt]

Hi, folks. I have an ATtiny3216F that I have just started playing with, and am trying to understand the clock speed options in the Arduino IDE using megaTinyCore, programming with an Arduino UNO via jtag2udpi.

Here's my code:

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

#define MS_DELAY 3000

int main (void)
{
  // Set PB1 to be output
  PORTB.DIR = 0b00000010;
  
  while (1) {
      // Set PB1 high
      PORTB.OUT = 0b00000010; 
      _delay_ms(MS_DELAY);
      
      // Set PB1 low
      PORTB.OUT = 0b00000000;
      _delay_ms(MS_DELAY);
  }
  
  return 0;
}

I have Clock Speed set to 1 MHz and mills()/micros() set to Enabled. I have an LED wired to PB1.

While running the code, I counted 19 full cycles of my LED flashing in 43.5 seconds. In other words, the while loop is running at ~0.44 Hz rather than the intended ~0.17 Hz. In other other words, the MCU is counting ~2290 ms as ~6000 ms.

3216 datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/ATtiny3216-17-DataSheet-DS40002205A.pdf

Here are my questions:

1. Does the mills()/micros() setting make any difference here?
2. How can I determine what the clock speed setting needs to be for the MCU to count ~6000 ms as ~6000 ms? I.e., is there some function that maps the clock speed to the actual length of a "ms" as counted by the MCU? Obviously, I have a lack of knowledge when it comes to oscillators/CPU clock speed.
3. Is the Clock Speed setting in the Arduino IDE, via megaTinyCore, saying "set your internal oscillator to this speed", or, is it saying "assume that you are wired to an external oscillator at this speed"?
4. I would like to use the 3216's "32.768 kHz Ultra Low-Power (ULP) internal RC oscillator." Is doing so possible with megaTinyCore?
5. Why is megaTinyCore offering clock options of 20, 16, 10, 8, 5, 4, and 1 MHz, when (it seems to me like) these aren't supported by the MCU? See sections 10.3.4 and 10.5.1 of the datasheet.

Thanks!

[grandaspanna]

I can't answer all of your questions, but for starters, have a good look at the diagram in 10.2.1, which describes how different clock sources can be used to drive different parts of the microcontroller.

The megaTinyCore takes care of mapping out the actual clock speed (or what it thinks it is) and ensuring that millis() and micros() are close to what they should be. I've got into the habit of using "Burn bootloader" before I upload sketches, since it sets fuses consistently with the sketch. The behaviour you're describing suggests a misalignment. You should not need to worry about "clock speed" etc unless you want to do some of your own playing with other timers.

As for specific questions:
4) Yes, absolutely. How you use it depends on your use case and requirements. One of the other discussion topics showed some examples.
5) While referencing the clock control diagram in 10.2.1 (figure 10-1), the internal oscillator can run at either 16 or 20MHz. The clock prescaler can run at a divisor of 1,2,4,8,16,32,64,6,10,24,48, so to get 5MHz (for example), choose the 20MHz internal oscillator and a prescaler of 4.

[nabelekt]

Thanks for the reply!

I do have the bootloader burnt with the same settings that I am uploading the sketch, so I am not sure why they would be misaligned if they are. Edit: it sounds from Spence’s answer like the problem is that I am not calling init().

4. So, what would the IDE settings have to be to disable the other oscillator, run at 32.768 kHz, and keep the MCU in Ultra Low-Power Mode? Edit: Reading the last sentence of Spence’s answer, I think the answer here is actually “no”.

5. I see, so, megaTinyCore is combining the oscillator and prescaler selections into one setting? I think the answer is yes, based on Spence’s answer.

Thanks again!

[SpenceKonde]

Yeah, it's that you're not calling init() (and more generally, that you're using an Arduino core to write something that is about as far from a typical Arduino sketch as possible)

4. You would need to write your own initialization function and call it from main if you wanted to run off the ULP. Really it sounds like what you'd be doing at that point is writing straight C and using Arduino and megaTinyCore as a a way to get a working toolchain pulled together..... ?
5. Yes, I'm sure you can tell which speeds are derived from 20 MHz and which from 16 MHz oscillator settings. The only ambiguous one is the 1 MHz - I use 16 for that; I figure generating 20 and dividing by 20 is less efficient than generating 16 and dividing by 16.

[nabelekt]

Do you think modifying init() to support ULP would be much trouble? I am thinking about giving it a shot and opening a PR.

Edit: On 4, yes, that's essentially what I'm doing, for better or worse.

[SpenceKonde]

On these parts, they start with prescale of 6, and then the user application can change that prescale. That is done by the megaTinyCore init() function which makes the CPU clock run at the selected speed from tools submenu. (whether it is derived from 16 MHz or 20 MHz depends on a fuse - this is set automatically to match the selected option when using the Arduino IDE to upload to non-Optiboot boards (Optiboot boards require a burn bootloader cycle, since normal uploads can't change their fuses))

However, you have overridden main - from which init() is called. Thus the clock controller is not configured to match your desired clock speed. The PWM timers to make analogWrite() work aren't set up either, nor is millis()/micros() timekeeping, The ADC is not configured.
Basically, nothing that the core sets up for you will be set up.
If you are overriding main (as opposed to using setup and loop like almost all of our users do - even I hardly ever have a good reason to override main!), you must call init() at the start of your main() - or do all of the initialization of on-chip peripherals manually.

There is no menu option that will make the speed match the startup speed, (which is either 2.66MHz or 3.33 MHz) because these are values for which the timekeeping math is very hard, and which nobody has a particular desire to use. (note though that the megaTinyCore bootloader for serial uploading does run at this speed, since it doesn't need timekeeping and does need to fit in 256 instruction words.

The millis/micros setting makes no difference until init is called (well, I think the ISR is still defined, but not enabled), because it is also configured in init() which is not being called because you overrode main.

Note that this is by no means unique to megaTinyCore - all Arduino cores will be practically non-functional without their init() being called; the modern AVRs more-so because they don;t have clock fully controlled by fuses (but on the plus side, you can't fuse these to use an external clock that isnt present and lock yourself out until you can supply one, you can just tell them to try to switch to one, and if it's not there, the chip will run off internal oscillator and I think I have it do a blink code (maybe only DxCore has that)

if you don't know much about this stuff, as you say, why are you using an advanced technique like overriding main and taking full control of program flow? It's an Arduino core - you can write Arduino sketches pretty much like you would for an Uno or similar, and not have to worry about configuring the clock, because that is done for you before setup is called :-P

megaTinyCore does not support the ultra-slow clock options. Didn't seem like there was a compelling use case for them, and a bunch of stuff doesn't make much sense in that context.

[nabelekt]

Thank you for the detailed response, all good info! This mostly makes sense to me.

I assumed that everything with the clock was being set in fuses in the bootloader burn process. But, I am taking a look at init() and see that it happens at runtime. I have added a call to init() to the top of my main(), and I now see roughly what I expect.

The motivation for overriding main is that this is a very early basis for a much larger project that will likely move out of the Arduino IDE at some point, and perhaps to a non-AVR MCU. I'm trying to get going quickly, but don't want to get too invested in the Arduino environment.

Could you elaborate on the "a bunch of stuff doesn't make much sense in that context" part of your last sentence?

[SpenceKonde]

Well, like PWM ? Reading analog voltages (ADC requires at least 1 50kHz clock, and minimum prescale is 2... There are a whole bunch of large parts of the Arduino API that are predicated on a F_CPU in the millions. I'm having trouble thinking of reasonable use cases that sleeping+interrupts and running for brief bursts at higher F_CPUI wouldn't be better for..