0

I read somewhere that having the main clock be 32768Hz messes not only with micros() and millis(), but with some other stuff too. Is this true? Will I have to forgo the Arduino IDE to program for an avr running at 32768Hz?

  • Do you still need to know if filter capacitors are required? electronics.stackexchange.com/questions/416523/… – VE7JRO Jan 12 at 2:33
  • @VE7JRO No. And are you able to answer this question? – Alexander M Jan 12 at 2:37
  • Sorry, I don't have a definitive answer for you. There is a debate about it here: forum.arduino.cc/index.php?topic=75397.0 – VE7JRO Jan 12 at 2:53
  • Please tell us why you want a main clock of 32.768kHz. Have you heard of the XY-problem xyproblem.info Most microcontrollers and processors that are used in arduino boards are capable to use a crystal of 32.768kHz but the arduino code is not for such a low clock. – Jot Jan 12 at 8:26
3

Yes, things will break. The main culpret is this:

#define clockCyclesPerMicrosecond() ( F_CPU / 1000000L )

With any value below 1000000 the result of that calculation will be 0.

That means code like micros() will break, since it uses:

return ((m << 8) + t) * (64 / clockCyclesPerMicrosecond());

64/0 is ... um ... yes... And whatever that ends up being is then multiplying the tick count. So ... the result of micros() is ... um ... yes...

In fact, when trying to compile anything you get (certainly on UECIDE):

• Error at line 103 in file wiring.c:
    ‣ division by zero [-Werror=div-by-zero]

Since that's erroring when compiling code there's not a lot you can do about it.

However, one idea does spring to mind - one that is a little "crazy" I guess.

  • Set your boards.txt entry to 3276800Hz

The calculations will all then be valid - however, they will all be out by a factor of 100.

With the board actually running at 32768, and the API thinking it runs at 3276800, all you need to do is use values 100x less than you would normally in your calculations.

For instance, to delay 1 second you'd use delay(10); instead of delay(1000);. Or you'd multiply the return value of millis() by 100 to get the real number of milliseconds.

Baud rates will have to be 100x faster - so use Serial.begin(960000); instead of Serial.begin(9600);.

Of course, the clockCyclesPerMicrosecond() is not geared towards working with values like 3276800, and F_CPU/1000000L will result in 3 not 3.2768 as you'd like, so timing calculations will be a little bit off. You may need to tweak things like baud rates accordingly to compensate.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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