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?
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
Of course, the
clockCyclesPerMicrosecond() is not geared towards working with values like 3276800, and
F_CPU/1000000L will result in
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.